@leaflow/sdk 0.0.0-dev.39.gc9098a0 → 0.0.0-dev.391.g0aed14e

package/dist/compute/v1/generated/validators/billingComponent.zod.d.ts

@@ -0,0 +1,54 @@
+/**
+ * Generated by orval 🍺
+ * Do not edit manually.
+ * Leaflow Compute API
+ * Leaflow Compute user API for managing instances, disks, snapshots, backups, images, private networks, subnets, routes, security groups, network interfaces and floating IPs.
+ *
+ * ## Authentication
+ *
+ * Every request carries a scoped token; see the `scopedTokenAuth` security scheme.
+ *
+ * ## Conventions
+ *
+ * - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
+ * - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices` and `search-rates`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
+ * - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
+ * - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
+ * - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
+ * - **Availability zones.** A disk and an instance must reside in the same availability zone to be attached. Instance types and disk types are each bound to one availability zone, so choosing a type determines the zone.
+ * - **IPv6 is not sold separately.** Once enabled on a private network, IPv6 addresses are assigned to the instances in that network automatically; they can be neither requested nor released individually.
+ * - **Floating IPs have a cooldown period.** A released address is neither available for re-allocation nor handed to another user for some time, so that DNS records and allow-lists still pointing at it do not break immediately.
+ * - **Passwords are returned once.** A password generated by the platform during creation or rebuild appears only in that response. Store it immediately.
+ * OpenAPI spec version: 1.0.0
+ */
+import * as zod from "zod";
+export declare const BillingComponent: zod.ZodObject<{
+    plan_id: zod.ZodUUID;
+    dimensions: zod.ZodRecord<zod.ZodString, zod.ZodString>;
+    quantity: zod.ZodObject<{
+        licensed: zod.ZodOptional<zod.ZodEnum<{
+            one: "one";
+            size_gib: "size_gib";
+            bandwidth_mbps: "bandwidth_mbps";
+            snapshots: "snapshots";
+        }>>;
+        metered: zod.ZodOptional<zod.ZodEnum<{
+            one: "one";
+            size_gib: "size_gib";
+            bandwidth_mbps: "bandwidth_mbps";
+            snapshots: "snapshots";
+        }>>;
+    }, zod.z.core.$strict>;
+    meters: zod.ZodArray<zod.ZodObject<{
+        meter_lookup_key: zod.ZodString;
+        quantity: zod.ZodEnum<{
+            one: "one";
+            size_gib: "size_gib";
+            bandwidth_mbps: "bandwidth_mbps";
+            stored_gib: "stored_gib";
+        }>;
+        dimensions: zod.ZodOptional<zod.ZodRecord<zod.ZodString, zod.ZodString>>;
+    }, zod.z.core.$strict>>;
+}, zod.z.core.$strict>;
+export type BillingComponent = zod.input<typeof BillingComponent>;
+export type BillingComponentOutput = zod.output<typeof BillingComponent>;

package/dist/compute/v1/generated/validators/billingComponent.zod.js

@@ -0,0 +1,43 @@
+/**
+ * Generated by orval 🍺
+ * Do not edit manually.
+ * Leaflow Compute API
+ * Leaflow Compute user API for managing instances, disks, snapshots, backups, images, private networks, subnets, routes, security groups, network interfaces and floating IPs.
+ *
+ * ## Authentication
+ *
+ * Every request carries a scoped token; see the `scopedTokenAuth` security scheme.
+ *
+ * ## Conventions
+ *
+ * - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
+ * - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices` and `search-rates`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
+ * - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
+ * - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
+ * - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
+ * - **Availability zones.** A disk and an instance must reside in the same availability zone to be attached. Instance types and disk types are each bound to one availability zone, so choosing a type determines the zone.
+ * - **IPv6 is not sold separately.** Once enabled on a private network, IPv6 addresses are assigned to the instances in that network automatically; they can be neither requested nor released individually.
+ * - **Floating IPs have a cooldown period.** A released address is neither available for re-allocation nor handed to another user for some time, so that DNS records and allow-lists still pointing at it do not break immediately.
+ * - **Passwords are returned once.** A password generated by the platform during creation or rebuild appears only in that response. Store it immediately.
+ * OpenAPI spec version: 1.0.0
+ */
+import * as zod from "zod";
+import { BillingMeter } from "./billingMeter.zod.js";
+import { BillingQuantity } from "./billingQuantity.zod.js";
+export const BillingComponent = zod
+    .strictObject({
+    plan_id: zod.uuid().describe("The Billing plan the line is ordered under."),
+    dimensions: zod
+        .record(zod.string(), zod.string())
+        .describe("The dimension values the order line carries."),
+    quantity: zod
+        .strictObject({
+        licensed: BillingQuantity.optional(),
+        metered: BillingQuantity.optional(),
+    })
+        .describe("What the order line's quantity counts, for each usage type the item is sold under. A usage type that is absent is not sold for this item."),
+    meters: zod
+        .array(BillingMeter)
+        .describe("What the line's metered price reads. Empty when the line is never metered or its usage is not estimated in advance."),
+})
+    .describe("How one order line of an item is sold in Billing. Give `plan_id` to Billing's `search-prices` for its prices, and `dimensions` to `search-rates` for the rates of a price that delegates to a rate card. Quote a purchase or a change with Billing's `get-quote` using these values, the quantity this describes and the chosen terms, and estimate metered usage with `estimate-usage` and `meters`.");

package/dist/compute/v1/generated/validators/billingMeter.zod.d.ts

@@ -0,0 +1,36 @@
+/**
+ * Generated by orval 🍺
+ * Do not edit manually.
+ * Leaflow Compute API
+ * Leaflow Compute user API for managing instances, disks, snapshots, backups, images, private networks, subnets, routes, security groups, network interfaces and floating IPs.
+ *
+ * ## Authentication
+ *
+ * Every request carries a scoped token; see the `scopedTokenAuth` security scheme.
+ *
+ * ## Conventions
+ *
+ * - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
+ * - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices` and `search-rates`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
+ * - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
+ * - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
+ * - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
+ * - **Availability zones.** A disk and an instance must reside in the same availability zone to be attached. Instance types and disk types are each bound to one availability zone, so choosing a type determines the zone.
+ * - **IPv6 is not sold separately.** Once enabled on a private network, IPv6 addresses are assigned to the instances in that network automatically; they can be neither requested nor released individually.
+ * - **Floating IPs have a cooldown period.** A released address is neither available for re-allocation nor handed to another user for some time, so that DNS records and allow-lists still pointing at it do not break immediately.
+ * - **Passwords are returned once.** A password generated by the platform during creation or rebuild appears only in that response. Store it immediately.
+ * OpenAPI spec version: 1.0.0
+ */
+import * as zod from "zod";
+export declare const BillingMeter: zod.ZodObject<{
+    meter_lookup_key: zod.ZodString;
+    quantity: zod.ZodEnum<{
+        one: "one";
+        size_gib: "size_gib";
+        bandwidth_mbps: "bandwidth_mbps";
+        stored_gib: "stored_gib";
+    }>;
+    dimensions: zod.ZodOptional<zod.ZodRecord<zod.ZodString, zod.ZodString>>;
+}, zod.z.core.$strict>;
+export type BillingMeter = zod.input<typeof BillingMeter>;
+export type BillingMeterOutput = zod.output<typeof BillingMeter>;

package/dist/compute/v1/generated/validators/billingMeter.zod.js

@@ -0,0 +1,34 @@
+/**
+ * Generated by orval 🍺
+ * Do not edit manually.
+ * Leaflow Compute API
+ * Leaflow Compute user API for managing instances, disks, snapshots, backups, images, private networks, subnets, routes, security groups, network interfaces and floating IPs.
+ *
+ * ## Authentication
+ *
+ * Every request carries a scoped token; see the `scopedTokenAuth` security scheme.
+ *
+ * ## Conventions
+ *
+ * - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
+ * - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices` and `search-rates`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
+ * - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
+ * - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
+ * - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
+ * - **Availability zones.** A disk and an instance must reside in the same availability zone to be attached. Instance types and disk types are each bound to one availability zone, so choosing a type determines the zone.
+ * - **IPv6 is not sold separately.** Once enabled on a private network, IPv6 addresses are assigned to the instances in that network automatically; they can be neither requested nor released individually.
+ * - **Floating IPs have a cooldown period.** A released address is neither available for re-allocation nor handed to another user for some time, so that DNS records and allow-lists still pointing at it do not break immediately.
+ * - **Passwords are returned once.** A password generated by the platform during creation or rebuild appears only in that response. Store it immediately.
+ * OpenAPI spec version: 1.0.0
+ */
+import * as zod from "zod";
+export const BillingMeter = zod.strictObject({
+    meter_lookup_key: zod.string(),
+    quantity: zod
+        .enum(["one", "size_gib", "bandwidth_mbps", "stored_gib"])
+        .describe("What the meter's quantity measures while the item exists: `one` is one item, `size_gib` its size in GiB, `bandwidth_mbps` its bandwidth in Mbps, `stored_gib` the GiB it stores."),
+    dimensions: zod
+        .record(zod.string(), zod.string())
+        .optional()
+        .describe("The dimension values the meter's usage carries, when they differ from the line's."),
+});

package/dist/compute/v1/generated/validators/billingPeriod.zod.d.ts

@@ -0,0 +1,34 @@
+/**
+ * Generated by orval 🍺
+ * Do not edit manually.
+ * Leaflow Compute API
+ * Leaflow Compute user API for managing instances, disks, snapshots, backups, images, private networks, subnets, routes, security groups, network interfaces and floating IPs.
+ *
+ * ## Authentication
+ *
+ * Every request carries a scoped token; see the `scopedTokenAuth` security scheme.
+ *
+ * ## Conventions
+ *
+ * - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
+ * - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices` and `search-rates`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
+ * - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
+ * - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
+ * - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
+ * - **Availability zones.** A disk and an instance must reside in the same availability zone to be attached. Instance types and disk types are each bound to one availability zone, so choosing a type determines the zone.
+ * - **IPv6 is not sold separately.** Once enabled on a private network, IPv6 addresses are assigned to the instances in that network automatically; they can be neither requested nor released individually.
+ * - **Floating IPs have a cooldown period.** A released address is neither available for re-allocation nor handed to another user for some time, so that DNS records and allow-lists still pointing at it do not break immediately.
+ * - **Passwords are returned once.** A password generated by the platform during creation or rebuild appears only in that response. Store it immediately.
+ * OpenAPI spec version: 1.0.0
+ */
+import * as zod from "zod";
+export declare const billingPeriodCountMax = 2147483647;
+export declare const BillingPeriod: zod.ZodObject<{
+    unit: zod.ZodEnum<{
+        month: "month";
+        year: "year";
+    }>;
+    count: zod.ZodInt;
+}, zod.z.core.$strict>;
+export type BillingPeriod = zod.input<typeof BillingPeriod>;
+export type BillingPeriodOutput = zod.output<typeof BillingPeriod>;

package/dist/compute/v1/generated/validators/billingPeriod.zod.js

@@ -0,0 +1,29 @@
+/**
+ * Generated by orval 🍺
+ * Do not edit manually.
+ * Leaflow Compute API
+ * Leaflow Compute user API for managing instances, disks, snapshots, backups, images, private networks, subnets, routes, security groups, network interfaces and floating IPs.
+ *
+ * ## Authentication
+ *
+ * Every request carries a scoped token; see the `scopedTokenAuth` security scheme.
+ *
+ * ## Conventions
+ *
+ * - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
+ * - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices` and `search-rates`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
+ * - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
+ * - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
+ * - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
+ * - **Availability zones.** A disk and an instance must reside in the same availability zone to be attached. Instance types and disk types are each bound to one availability zone, so choosing a type determines the zone.
+ * - **IPv6 is not sold separately.** Once enabled on a private network, IPv6 addresses are assigned to the instances in that network automatically; they can be neither requested nor released individually.
+ * - **Floating IPs have a cooldown period.** A released address is neither available for re-allocation nor handed to another user for some time, so that DNS records and allow-lists still pointing at it do not break immediately.
+ * - **Passwords are returned once.** A password generated by the platform during creation or rebuild appears only in that response. Store it immediately.
+ * OpenAPI spec version: 1.0.0
+ */
+import * as zod from "zod";
+export const billingPeriodCountMax = 2147483647;
+export const BillingPeriod = zod.strictObject({
+    unit: zod.enum(["month", "year"]),
+    count: zod.int().min(1).max(billingPeriodCountMax),
+});

package/dist/compute/v1/generated/validators/billingQuantity.zod.d.ts

@@ -0,0 +1,32 @@
+/**
+ * Generated by orval 🍺
+ * Do not edit manually.
+ * Leaflow Compute API
+ * Leaflow Compute user API for managing instances, disks, snapshots, backups, images, private networks, subnets, routes, security groups, network interfaces and floating IPs.
+ *
+ * ## Authentication
+ *
+ * Every request carries a scoped token; see the `scopedTokenAuth` security scheme.
+ *
+ * ## Conventions
+ *
+ * - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
+ * - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices` and `search-rates`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
+ * - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
+ * - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
+ * - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
+ * - **Availability zones.** A disk and an instance must reside in the same availability zone to be attached. Instance types and disk types are each bound to one availability zone, so choosing a type determines the zone.
+ * - **IPv6 is not sold separately.** Once enabled on a private network, IPv6 addresses are assigned to the instances in that network automatically; they can be neither requested nor released individually.
+ * - **Floating IPs have a cooldown period.** A released address is neither available for re-allocation nor handed to another user for some time, so that DNS records and allow-lists still pointing at it do not break immediately.
+ * - **Passwords are returned once.** A password generated by the platform during creation or rebuild appears only in that response. Store it immediately.
+ * OpenAPI spec version: 1.0.0
+ */
+import * as zod from "zod";
+export declare const BillingQuantity: zod.ZodEnum<{
+    one: "one";
+    size_gib: "size_gib";
+    bandwidth_mbps: "bandwidth_mbps";
+    snapshots: "snapshots";
+}>;
+export type BillingQuantity = zod.input<typeof BillingQuantity>;
+export type BillingQuantityOutput = zod.output<typeof BillingQuantity>;

package/dist/compute/v1/generated/validators/billingQuantity.zod.js

@@ -0,0 +1,27 @@
+/**
+ * Generated by orval 🍺
+ * Do not edit manually.
+ * Leaflow Compute API
+ * Leaflow Compute user API for managing instances, disks, snapshots, backups, images, private networks, subnets, routes, security groups, network interfaces and floating IPs.
+ *
+ * ## Authentication
+ *
+ * Every request carries a scoped token; see the `scopedTokenAuth` security scheme.
+ *
+ * ## Conventions
+ *
+ * - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
+ * - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices` and `search-rates`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
+ * - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
+ * - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
+ * - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
+ * - **Availability zones.** A disk and an instance must reside in the same availability zone to be attached. Instance types and disk types are each bound to one availability zone, so choosing a type determines the zone.
+ * - **IPv6 is not sold separately.** Once enabled on a private network, IPv6 addresses are assigned to the instances in that network automatically; they can be neither requested nor released individually.
+ * - **Floating IPs have a cooldown period.** A released address is neither available for re-allocation nor handed to another user for some time, so that DNS records and allow-lists still pointing at it do not break immediately.
+ * - **Passwords are returned once.** A password generated by the platform during creation or rebuild appears only in that response. Store it immediately.
+ * OpenAPI spec version: 1.0.0
+ */
+import * as zod from "zod";
+export const BillingQuantity = zod
+    .enum(["one", "size_gib", "bandwidth_mbps", "snapshots"])
+    .describe("`one`: one per item. `size_gib`: the size or capacity bought, in GiB. `bandwidth_mbps`: the bandwidth bought, in Mbps. `snapshots`: the number of snapshots the quota allows.");

package/dist/compute/v1/generated/validators/bindFloatingIPRequestBody.zod.d.ts

@@ -0,0 +1,29 @@
+/**
+ * Generated by orval 🍺
+ * Do not edit manually.
+ * Leaflow Compute API
+ * Leaflow Compute user API for managing instances, disks, snapshots, backups, images, private networks, subnets, routes, security groups, network interfaces and floating IPs.
+ *
+ * ## Authentication
+ *
+ * Every request carries a scoped token; see the `scopedTokenAuth` security scheme.
+ *
+ * ## Conventions
+ *
+ * - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
+ * - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices` and `search-rates`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
+ * - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
+ * - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
+ * - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
+ * - **Availability zones.** A disk and an instance must reside in the same availability zone to be attached. Instance types and disk types are each bound to one availability zone, so choosing a type determines the zone.
+ * - **IPv6 is not sold separately.** Once enabled on a private network, IPv6 addresses are assigned to the instances in that network automatically; they can be neither requested nor released individually.
+ * - **Floating IPs have a cooldown period.** A released address is neither available for re-allocation nor handed to another user for some time, so that DNS records and allow-lists still pointing at it do not break immediately.
+ * - **Passwords are returned once.** A password generated by the platform during creation or rebuild appears only in that response. Store it immediately.
+ * OpenAPI spec version: 1.0.0
+ */
+import * as zod from "zod";
+export declare const BindFloatingIPRequestBody: zod.ZodObject<{
+    port_address_id: zod.ZodUUID;
+}, zod.z.core.$strict>;
+export type BindFloatingIPRequestBody = zod.input<typeof BindFloatingIPRequestBody>;
+export type BindFloatingIPRequestBodyOutput = zod.output<typeof BindFloatingIPRequestBody>;

package/dist/compute/v1/generated/validators/bindFloatingIPRequestBody.zod.js

@@ -0,0 +1,27 @@
+/**
+ * Generated by orval 🍺
+ * Do not edit manually.
+ * Leaflow Compute API
+ * Leaflow Compute user API for managing instances, disks, snapshots, backups, images, private networks, subnets, routes, security groups, network interfaces and floating IPs.
+ *
+ * ## Authentication
+ *
+ * Every request carries a scoped token; see the `scopedTokenAuth` security scheme.
+ *
+ * ## Conventions
+ *
+ * - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
+ * - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices` and `search-rates`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
+ * - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
+ * - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
+ * - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
+ * - **Availability zones.** A disk and an instance must reside in the same availability zone to be attached. Instance types and disk types are each bound to one availability zone, so choosing a type determines the zone.
+ * - **IPv6 is not sold separately.** Once enabled on a private network, IPv6 addresses are assigned to the instances in that network automatically; they can be neither requested nor released individually.
+ * - **Floating IPs have a cooldown period.** A released address is neither available for re-allocation nor handed to another user for some time, so that DNS records and allow-lists still pointing at it do not break immediately.
+ * - **Passwords are returned once.** A password generated by the platform during creation or rebuild appears only in that response. Store it immediately.
+ * OpenAPI spec version: 1.0.0
+ */
+import * as zod from "zod";
+export const BindFloatingIPRequestBody = zod.strictObject({
+    port_address_id: zod.uuid(),
+});

package/dist/compute/v1/generated/validators/bootDisk.zod.d.ts

@@ -0,0 +1,58 @@
+/**
+ * Generated by orval 🍺
+ * Do not edit manually.
+ * Leaflow Compute API
+ * Leaflow Compute user API for managing instances, disks, snapshots, backups, images, private networks, subnets, routes, security groups, network interfaces and floating IPs.
+ *
+ * ## Authentication
+ *
+ * Every request carries a scoped token; see the `scopedTokenAuth` security scheme.
+ *
+ * ## Conventions
+ *
+ * - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
+ * - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices` and `search-rates`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
+ * - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
+ * - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
+ * - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
+ * - **Availability zones.** A disk and an instance must reside in the same availability zone to be attached. Instance types and disk types are each bound to one availability zone, so choosing a type determines the zone.
+ * - **IPv6 is not sold separately.** Once enabled on a private network, IPv6 addresses are assigned to the instances in that network automatically; they can be neither requested nor released individually.
+ * - **Floating IPs have a cooldown period.** A released address is neither available for re-allocation nor handed to another user for some time, so that DNS records and allow-lists still pointing at it do not break immediately.
+ * - **Passwords are returned once.** A password generated by the platform during creation or rebuild appears only in that response. Store it immediately.
+ * OpenAPI spec version: 1.0.0
+ */
+import * as zod from "zod";
+export declare const BootDisk: zod.ZodDiscriminatedUnion<[zod.ZodObject<{
+    type: zod.ZodEnum<{
+        image: "image";
+    }>;
+    image_id: zod.ZodUUID;
+    disk_type_id: zod.ZodUUID;
+    size_gb: zod.ZodInt;
+    delete_with_instance: zod.ZodDefault<zod.ZodBoolean>;
+    billing: zod.ZodObject<{
+        usage_type: zod.ZodEnum<{
+            licensed: "licensed";
+            metered: "metered";
+        }>;
+        period: zod.ZodOptional<zod.ZodObject<{
+            unit: zod.ZodEnum<{
+                month: "month";
+                year: "year";
+            }>;
+            count: zod.ZodInt;
+        }, zod.z.core.$strict>>;
+        termination_policy: zod.ZodOptional<zod.ZodEnum<{
+            immediate: "immediate";
+            period_end: "period_end";
+        }>>;
+    }, zod.z.core.$strict>;
+}, zod.z.core.$strict>, zod.ZodObject<{
+    type: zod.ZodEnum<{
+        disk: "disk";
+    }>;
+    disk_id: zod.ZodUUID;
+    login_username: zod.ZodString;
+}, zod.z.core.$strict>], "type">;
+export type BootDisk = zod.input<typeof BootDisk>;
+export type BootDiskOutput = zod.output<typeof BootDisk>;

package/dist/compute/v1/generated/validators/bootDisk.zod.js

@@ -0,0 +1,29 @@
+/**
+ * Generated by orval 🍺
+ * Do not edit manually.
+ * Leaflow Compute API
+ * Leaflow Compute user API for managing instances, disks, snapshots, backups, images, private networks, subnets, routes, security groups, network interfaces and floating IPs.
+ *
+ * ## Authentication
+ *
+ * Every request carries a scoped token; see the `scopedTokenAuth` security scheme.
+ *
+ * ## Conventions
+ *
+ * - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
+ * - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices` and `search-rates`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
+ * - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
+ * - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
+ * - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
+ * - **Availability zones.** A disk and an instance must reside in the same availability zone to be attached. Instance types and disk types are each bound to one availability zone, so choosing a type determines the zone.
+ * - **IPv6 is not sold separately.** Once enabled on a private network, IPv6 addresses are assigned to the instances in that network automatically; they can be neither requested nor released individually.
+ * - **Floating IPs have a cooldown period.** A released address is neither available for re-allocation nor handed to another user for some time, so that DNS records and allow-lists still pointing at it do not break immediately.
+ * - **Passwords are returned once.** A password generated by the platform during creation or rebuild appears only in that response. Store it immediately.
+ * OpenAPI spec version: 1.0.0
+ */
+import * as zod from "zod";
+import { ExistingBootDisk } from "./existingBootDisk.zod.js";
+import { NewBootDisk } from "./newBootDisk.zod.js";
+export const BootDisk = zod
+    .discriminatedUnion("type", [NewBootDisk, ExistingBootDisk])
+    .describe("Create a boot disk from an image, or use a prepared disk already held by this project. Using an existing disk does not buy it again and always keeps it when the instance is released.");

package/dist/compute/v1/generated/validators/checkoutMode.zod.d.ts

@@ -0,0 +1,30 @@
+/**
+ * Generated by orval 🍺
+ * Do not edit manually.
+ * Leaflow Compute API
+ * Leaflow Compute user API for managing instances, disks, snapshots, backups, images, private networks, subnets, routes, security groups, network interfaces and floating IPs.
+ *
+ * ## Authentication
+ *
+ * Every request carries a scoped token; see the `scopedTokenAuth` security scheme.
+ *
+ * ## Conventions
+ *
+ * - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
+ * - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices` and `search-rates`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
+ * - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
+ * - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
+ * - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
+ * - **Availability zones.** A disk and an instance must reside in the same availability zone to be attached. Instance types and disk types are each bound to one availability zone, so choosing a type determines the zone.
+ * - **IPv6 is not sold separately.** Once enabled on a private network, IPv6 addresses are assigned to the instances in that network automatically; they can be neither requested nor released individually.
+ * - **Floating IPs have a cooldown period.** A released address is neither available for re-allocation nor handed to another user for some time, so that DNS records and allow-lists still pointing at it do not break immediately.
+ * - **Passwords are returned once.** A password generated by the platform during creation or rebuild appears only in that response. Store it immediately.
+ * OpenAPI spec version: 1.0.0
+ */
+import * as zod from "zod";
+export declare const CheckoutMode: zod.ZodEnum<{
+    automatic: "automatic";
+    deferred: "deferred";
+}>;
+export type CheckoutMode = zod.input<typeof CheckoutMode>;
+export type CheckoutModeOutput = zod.output<typeof CheckoutMode>;

package/dist/compute/v1/generated/validators/checkoutMode.zod.js

@@ -0,0 +1,27 @@
+/**
+ * Generated by orval 🍺
+ * Do not edit manually.
+ * Leaflow Compute API
+ * Leaflow Compute user API for managing instances, disks, snapshots, backups, images, private networks, subnets, routes, security groups, network interfaces and floating IPs.
+ *
+ * ## Authentication
+ *
+ * Every request carries a scoped token; see the `scopedTokenAuth` security scheme.
+ *
+ * ## Conventions
+ *
+ * - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
+ * - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices` and `search-rates`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
+ * - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
+ * - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
+ * - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
+ * - **Availability zones.** A disk and an instance must reside in the same availability zone to be attached. Instance types and disk types are each bound to one availability zone, so choosing a type determines the zone.
+ * - **IPv6 is not sold separately.** Once enabled on a private network, IPv6 addresses are assigned to the instances in that network automatically; they can be neither requested nor released individually.
+ * - **Floating IPs have a cooldown period.** A released address is neither available for re-allocation nor handed to another user for some time, so that DNS records and allow-lists still pointing at it do not break immediately.
+ * - **Passwords are returned once.** A password generated by the platform during creation or rebuild appears only in that response. Store it immediately.
+ * OpenAPI spec version: 1.0.0
+ */
+import * as zod from "zod";
+export const CheckoutMode = zod
+    .enum(["automatic", "deferred"])
+    .describe("automatic completes checkout with the purchase: the best applicable account discount is applied, and the\norder is created with its invoice issued and paid from eligible credit grants and available balance.\nInsufficient funds fail the purchase with HTTP 422 BILLING_INSUFFICIENT_FUNDS; no Billing order, charge or\ndiscount redemption is committed.\ndeferred creates an open Billing Checkout Session and charges nothing, even for a zero total. The customer\ncompletes it through Billing, where a promotion code can be applied, and then pays the issued invoice; a\nsession not completed by its deadline expires.");