diff --git a/api/billing/billingaccount.mdx b/api/billing/billingaccount.mdx new file mode 100644 index 0000000..b662d24 --- /dev/null +++ b/api/billing/billingaccount.mdx @@ -0,0 +1,99 @@ +--- +title: "BillingAccount" +sidebarTitle: "BillingAccount" +description: "BillingAccount is the Schema for the billingaccounts API. It represents a billing entity within an organization that is responsible for paying for service consumption." +--- + + + API resource reference for **BillingAccount**, part of the [Billing service](/api/billing/overview). To create or change one, see [Changing resources](/datumctl/resources/changing); to inspect, see [Reading resources](/datumctl/resources/reading). + + + + This resource is part of the `v1alpha1` API and is subject to change. Fields and behavior may change in future releases. + + +## Identity + +| | | +| --- | --- | +| Group | `billing.miloapis.com` | +| Version | `v1alpha1` | +| Kind | `BillingAccount` | +| Scope | Project | + +## Overview + +A `BillingAccount` represents the paying entity within an organization that is charged for service consumption. Use it to record who is billed, the currency invoices are issued in, the postal contact and address printed on invoices, the default payment method used to process charges, the invoicing schedule, and any tax registrations that apply to the account. + +## Spec fields + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `spec.currencyCode` | string | Yes | ISO 4217 currency code for this billing account. Immutable once the account transitions past the Provisioning phase. | +| `spec.contactInfo` | Object | No | Billing contact and the postal address invoices are issued to. | +| `spec.contactInfo.email` | string | Yes* | Primary billing contact email. Receives billing notifications and, when `invoiceEmails` is unset, also receives invoices and receipts. (*Required when `contactInfo` is set.) | +| `spec.contactInfo.name` | string | No | Display name of the individual billing contact. Appears as the "ATTN:" line on invoices when `businessName` is also set. | +| `spec.contactInfo.businessName` | string | No | Legal entity that pays. Populate for B2B accounts so invoices print the company name; maps onto the provider `Customer.name`. | +| `spec.contactInfo.invoiceEmails` | []string | No | Recipients for invoices and receipts. First entry is primary, the rest are CC'd. Duplicates rejected; maximum 10 entries. | +| `spec.contactInfo.address` | Object | No | Postal billing address. Appears on invoices and is surfaced to the provider controller for tax determination and address verification. | +| `spec.contactInfo.address.country` | string | Yes* | ISO 3166-1 alpha-2 country code (e.g. `GB`, `US`). (*Required when `address` is set — tax and currency restrictions depend on it.) | +| `spec.contactInfo.address.line1` | string | No | First line of the street address (typically number + street). | +| `spec.contactInfo.address.line2` | string | No | Second line of the street address (apartment / suite / building). | +| `spec.contactInfo.address.city` | string | No | Locality. | +| `spec.contactInfo.address.region` | string | No | State, province, or county (free-form). | +| `spec.contactInfo.address.postalCode` | string | No | Post / zip code. | +| `spec.defaultPaymentMethodRef` | Object | No | References the `PaymentMethod` used by default for charge processing. Must reside in the same Project and be in the Active phase. | +| `spec.defaultPaymentMethodRef.name` | string | Yes* | Name of the referenced `PaymentMethod`. (*Required when the reference is set.) | +| `spec.paymentTerms` | Object | No | Invoicing schedule for this billing account. | +| `spec.paymentTerms.invoiceFrequency` | string | No | How often invoices are generated. One of `Monthly`, `Quarterly`, `Annual`. | +| `spec.paymentTerms.invoiceDayOfMonth` | integer | No | Day of the month invoices are generated. | +| `spec.paymentTerms.netDays` | integer | No | Number of days after the invoice date that payment is due. | +| `spec.taxIds` | []Object | No | Tax registrations attached to this account. An account can carry multiple entries. | +| `spec.taxIds[].type` | string | Yes* | Tax registration scheme, following a `_` convention (e.g. `gb_vat`, `eu_vat`, `us_ein`). (*Required per entry.) | +| `spec.taxIds[].value` | string | Yes* | Registration number / identifier (e.g. `GB123456789`). (*Required per entry.) | + +## Status fields (read-only) + +| Field | Type | Description | +| --- | --- | --- | +| `status.phase` | string | Current lifecycle phase. One of `Provisioning`, `Ready`, `Suspended`, `Archived`. | +| `status.linkedProjectsCount` | integer | Number of projects currently bound to this billing account. | +| `status.conditions` | []Object | Latest available observations of the billing account's state. | +| `status.observedGeneration` | integer | Most recent generation observed by the controller. | + +## Usage + +```yaml +apiVersion: billing.miloapis.com/v1alpha1 +kind: BillingAccount +metadata: + name: acme-billing +spec: + currencyCode: GBP + contactInfo: + email: billing@acme.example + name: Jane Doe + businessName: Acme Ltd + address: + country: GB + line1: 1 High Street + city: London + postalCode: SW1A 1AA + paymentTerms: + invoiceFrequency: Monthly + invoiceDayOfMonth: 1 + netDays: 30 + taxIds: + - type: gb_vat + value: GB123456789 +``` + +```bash +datumctl apply -f billingaccount.yaml --project my-project +datumctl get billingaccounts --project my-project +datumctl describe billingaccount acme-billing --project my-project +``` + + + Run `datumctl explain billingaccounts --recursive` to see the full, live field tree for this resource. + diff --git a/api/billing/billingaccountbinding.mdx b/api/billing/billingaccountbinding.mdx new file mode 100644 index 0000000..d3fccb5 --- /dev/null +++ b/api/billing/billingaccountbinding.mdx @@ -0,0 +1,72 @@ +--- +title: "BillingAccountBinding" +sidebarTitle: "BillingAccountBinding" +description: "BillingAccountBinding links a project to a billing account, establishing billing responsibility for the project's resource consumption." +--- + + + API resource reference for **BillingAccountBinding**, part of the [Billing service](/api/billing/overview). To create or change one, see [Changing resources](/datumctl/resources/changing); to inspect, see [Reading resources](/datumctl/resources/reading). + + + + This resource is part of the `v1alpha1` API and is subject to change. Fields and behavior may change in future releases. + + +## Identity + +| | | +| --- | --- | +| Group | `billing.miloapis.com` | +| Version | `v1alpha1` | +| Kind | `BillingAccountBinding` | +| Scope | Project | + +## Overview + +A `BillingAccountBinding` connects a Project to a billing account so that the Project's resource consumption is charged to that account. Creating a binding establishes billing responsibility for the Project; the platform tracks which account is currently responsible and when that responsibility took effect. + +All fields in the spec are immutable once the binding is created. To move a Project to a different billing account, create a new binding — the previous one moves to the `Superseded` phase. + +## Spec fields + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `spec.billingAccountRef` | Object | Yes | References the billing account to bind. | +| `spec.billingAccountRef.name` | string | Yes | Name of the BillingAccount. | +| `spec.projectRef` | Object | Yes | References the project to bind to the billing account. | +| `spec.projectRef.name` | string | Yes | Name of the project. | + +## Status fields (read-only) + +| Field | Type | Description | +| --- | --- | --- | +| `status.phase` | string | Current lifecycle phase of the binding. One of `Active` or `Superseded`. | +| `status.billingResponsibility` | Object | Tracks when billing responsibility was established for this binding. | +| `status.billingResponsibility.currentAccount` | string | Name of the currently responsible billing account. | +| `status.billingResponsibility.establishedAt` | string | Time when billing responsibility was established. | +| `status.conditions` | []Object | Latest available observations of the binding's state. | +| `status.observedGeneration` | integer | Most recent generation observed by the controller. | + +## Usage + +```yaml +apiVersion: billing.miloapis.com/v1alpha1 +kind: BillingAccountBinding +metadata: + name: my-project-billing +spec: + billingAccountRef: + name: acme-billing-account + projectRef: + name: my-project +``` + +```bash +datumctl apply -f billingaccountbinding.yaml --project my-project +datumctl get billingaccountbindings --project my-project +datumctl describe billingaccountbindings my-project-billing --project my-project +``` + + + Run `datumctl explain billingaccountbindings --recursive` to see the full, live field tree for this resource. + diff --git a/api/billing/overview.mdx b/api/billing/overview.mdx new file mode 100644 index 0000000..7a85f31 --- /dev/null +++ b/api/billing/overview.mdx @@ -0,0 +1,34 @@ +--- +title: "Billing" +sidebarTitle: "Overview" +description: "Billing on Datum Cloud — billing accounts, the projects bound to them, and the payment methods that fund service consumption." +--- + +Datum Cloud manages billing through the `billing.miloapis.com` API. A **billing account** is the entity within an organization responsible for paying for service consumption; you bind projects to it so their usage rolls up to a single payer, and you attach payment methods that fund the account. Billing accounts and payment methods are created with `datumctl apply -f` and inspected with `datumctl get` and `datumctl describe`. + + + The Billing API is **alpha** (`v1alpha1`). Fields and behavior may change in backward-incompatible ways between releases. + + +## Resources + + + + A billing entity within an organization that is responsible for paying for service consumption. + + + Links a project to a billing account, establishing billing responsibility for the project's resource consumption. + + + Associates a payment instrument with a billing account to fund it. + + + + + Inspect the exact fields for any resource with `datumctl explain`, for example `datumctl explain billingaccounts.spec` or `datumctl explain paymentmethods.spec`. + + +## Learn more + +- [API resources overview](/api/overview) — the resource reference landing page across all Datum Cloud services. +- [Changing resources](/datumctl/resources/changing) — how to apply, edit, and safely preview changes to these resources. diff --git a/api/billing/paymentmethod.mdx b/api/billing/paymentmethod.mdx new file mode 100644 index 0000000..6fb11a5 --- /dev/null +++ b/api/billing/paymentmethod.mdx @@ -0,0 +1,75 @@ +--- +title: "PaymentMethod" +sidebarTitle: "PaymentMethod" +description: "PaymentMethod is the Schema for the paymentmethods API." +--- + + + API resource reference for **PaymentMethod**, part of the [Billing service](/api/billing/overview). To create or change one, see [Changing resources](/datumctl/resources/changing); to inspect, see [Reading resources](/datumctl/resources/reading). + + + + This resource is part of the `v1alpha1` API and is subject to change. Fields and behavior may change in future releases. + + +## Identity + +| | | +| --- | --- | +| Group | `billing.miloapis.com` | +| Version | `v1alpha1` | +| Kind | `PaymentMethod` | +| Scope | Project | + +## Overview + +A `PaymentMethod` associates a payment instrument — such as a credit card or US bank account — with a `BillingAccount`. You create one carrying only a reference to the billing account and a human-readable display name. The billing service then injects the `PaymentMethodClass` that selects the provider, and the provider controller drives the setup flow and reports the confirmed instrument back on `status` once it is active. + +Use it when you need to register a new way to pay for a billing account within a Project. + +## Spec fields + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `spec.billingAccountRef` | Object | Yes | References the `BillingAccount` this payment method belongs to. The BillingAccount must reside in the same Project. | +| `spec.billingAccountRef.name` | string | Yes | The name of the `BillingAccount`. | +| `spec.displayName` | string | Yes | A human-readable label shown in the portal and on invoices (e.g., `Corporate Visa`). | +| `spec.paymentMethodClassRef` | Object | No | Selects the `PaymentMethodClass` — and through it the provider controller — that owns the setup flow. Left unset by consumers and injected by the defaulting webhook. Immutable once set. | +| `spec.paymentMethodClassRef.name` | string | No | The name of the `PaymentMethodClass`. | + +## Status fields (read-only) + +| Field | Type | Description | +| --- | --- | --- | +| `status.phase` | string | Current lifecycle phase: `Pending`, `AwaitingConfirmation`, `Active`, or `Failed`. | +| `status.details` | Object | Normalized, provider-agnostic description of the confirmed instrument. Populated once the phase reaches `Active`. | +| `status.details.type` | string | The instrument category: `card` or `usBankAccount`. | +| `status.details.card` | Object | Card details, populated when `type` is `card`. | +| `status.details.usBankAccount` | Object | US bank account details, populated when `type` is `usBankAccount`. | +| `status.failureReason` | string | Short, machine-parseable failure code (e.g., `card_declined`). Set when phase is `Failed`. | +| `status.failureMessage` | string | Human-readable description of the failure. | +| `status.conditions` | []Object | Latest available observations of the payment method's state. | +| `status.observedGeneration` | integer | Most recent generation observed by the reconciling controller. | + +## Usage + +```yaml +apiVersion: billing.miloapis.com/v1alpha1 +kind: PaymentMethod +metadata: + name: corporate-visa +spec: + billingAccountRef: + name: acme-billing + displayName: Corporate Visa +``` + +```bash +datumctl apply -f paymentmethod.yaml --project my-project +datumctl get paymentmethods --project my-project +datumctl describe paymentmethod corporate-visa --project my-project +``` + + + Run `datumctl explain paymentmethods --recursive` to see the full, live field tree for this resource. + diff --git a/api/compute/instance.mdx b/api/compute/instance.mdx new file mode 100644 index 0000000..fb7d4bd --- /dev/null +++ b/api/compute/instance.mdx @@ -0,0 +1,91 @@ +--- +title: "Instance" +sidebarTitle: "Instance" +description: "Instance is the Schema for the instances API." +--- + + + API resource reference for **Instance**, part of the [Compute service](/api/compute/overview). To create or change one, see [Changing resources](/datumctl/resources/changing); to inspect, see [Reading resources](/datumctl/resources/reading). + + + + This resource is part of the `v1alpha` API and is subject to change. Fields and behavior may change in future releases. + + +## Identity + +| | | +| --- | --- | +| Group | `compute.datumapis.com` | +| Version | `v1alpha` | +| Kind | `Instance` | +| Scope | Project | + +## Overview + +An `Instance` represents a single compute workload running in a Datum Cloud Project. Each instance runs one of two runtime types: a **sandbox** (a managed, isolated environment for running one or more containers) or a **virtual machine** (a classical VM booting a full OS from a user-provided image). Every instance attaches to one or more networks through its network interfaces and may mount volumes backed by disks, config maps, or secrets. + +Use an `Instance` when you need to run application code — as containers or as a full VM — with a defined instance type, network connectivity, and optional persistent storage inside a Project. + +## Spec fields + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `spec.runtime` | Object | Yes | The runtime type of the instance, such as a container sandbox or a VM. | +| `spec.runtime.resources` | Object | Yes | Resources each instance must be allocated across its containers or VM. | +| `spec.runtime.resources.instanceType` | string | Yes | Full or partial URL of the instance type resource to use (for example, `datumcloud/d1-standard-2`). | +| `spec.runtime.resources.requests` | map[string]Object | No | Adjustments to the resources defined by the instance type (for customizable instance families). | +| `spec.runtime.sandbox` | Object | No | A managed isolated environment capable of running containers. | +| `spec.runtime.sandbox.containers` | []Object | Yes (if sandbox) | The containers to run within the sandbox; each requires a `name` and `image`. | +| `spec.runtime.sandbox.imagePullSecrets` | []Object | No | Secrets in the same Project used for pulling images. | +| `spec.runtime.virtualMachine` | Object | No | A classical VM environment booting a full OS from a user-provided image. | +| `spec.runtime.virtualMachine.volumeAttachments` | []Object | Yes (if VM) | Volumes to attach to the VM. | +| `spec.runtime.virtualMachine.ports` | []Object | No | Named ports for the virtual machine. | +| `spec.networkInterfaces` | []Object | Yes | Network interface configuration for the instance. | +| `spec.networkInterfaces[].network` | Object | Yes | The network to attach the interface to; `network.name` is required. | +| `spec.networkInterfaces[].networkPolicy` | Object | No | An interface-specific, platform-managed network policy targeting this interface. | +| `spec.volumes` | []Object | No | Volumes available to attach to the instance's containers or VM. | +| `spec.volumes[].name` | string | Yes (per volume) | Name used to reference the volume in container/VM volume attachments. | +| `spec.volumes[].disk` | Object | No | A persistent disk backed volume. | +| `spec.volumes[].configMap` | Object | No | A config map that populates this volume. | +| `spec.volumes[].secret` | Object | No | A secret that populates this volume. | +| `spec.location` | Object | No | The location the instance has been scheduled to (`name` and `namespace`). | +| `spec.controller` | Object | No | Settings driven by the controller managing the instance, including `templateHash` and `schedulingGates`. | + +## Status fields (read-only) + +| Field | Type | Description | +| --- | --- | --- | +| `status.conditions` | []Object | Observations of the instance's current state; known types are `Available` and `Progressing`. | +| `status.controller` | Object | Controller status, including the `observedTemplateHash` last applied to this instance. | +| `status.networkInterfaces` | []Object | Network interface information, including address assignments. | + +## Usage + +```yaml +apiVersion: compute.datumapis.com/v1alpha +kind: Instance +metadata: + name: web-server +spec: + runtime: + resources: + instanceType: datumcloud/d1-standard-2 + sandbox: + containers: + - name: web + image: nginx:1.27 + networkInterfaces: + - network: + name: default +``` + +```bash +datumctl apply -f instance.yaml --project my-project +datumctl get instances --project my-project +datumctl describe instance web-server --project my-project +``` + + + Run `datumctl explain instances --recursive` to see the full, live field tree for this resource. + diff --git a/api/compute/overview.mdx b/api/compute/overview.mdx new file mode 100644 index 0000000..f8fa25d --- /dev/null +++ b/api/compute/overview.mdx @@ -0,0 +1,40 @@ +--- +title: "Compute" +sidebarTitle: "Overview" +description: "Run workloads on Datum Cloud — the workloads you declare, the deployments that place them, and the instances that run them." +--- + +Datum Cloud runs your applications through the `compute.datumapis.com` API. You declare a workload describing what to run and how it should be shaped, Datum places it across the requested locations as deployments, and each deployment brings up the instances that actually run your code. Workloads and their derived resources are Project resources you create with `datumctl apply -f`. + + + The Compute API is **alpha** (`v1alpha`). Fields and behavior may change in backward-incompatible ways between releases. + + +## Resources + + + + The application you want to run — its template, resource shape, and placement policy. The top-level resource you author. + + + A placement of a workload derived from its policy, reconciled toward a target location. + + + A single running unit created by a deployment, reporting its own runtime state. + + + +## How the pieces fit together + +- A **Workload** is the resource you author. It declares what to run and its placement policy. +- A **WorkloadDeployment** is derived from a workload's placement policy, one per target location, and drives the desired state for that location. +- An **Instance** is the running unit brought up by a deployment; its status reports the observed runtime state. + + + Inspect the exact fields for any resource with `datumctl explain`, for example `datumctl explain workloads.spec` or `datumctl explain instances.spec`. + + +## Learn more + +- [API resources overview](/api/overview) — the resource reference landing page across all Datum Cloud services. +- [Changing resources](/datumctl/resources/changing) — how to apply, edit, and safely preview changes to these resources. diff --git a/api/compute/workload.mdx b/api/compute/workload.mdx new file mode 100644 index 0000000..e6f8e1c --- /dev/null +++ b/api/compute/workload.mdx @@ -0,0 +1,108 @@ +--- +title: "Workload" +sidebarTitle: "Workload" +description: "Workload is the Schema for the workloads API." +--- + + + API resource reference for **Workload**, part of the [Compute service](/api/compute/overview). To create or change one, see [Changing resources](/datumctl/resources/changing); to inspect, see [Reading resources](/datumctl/resources/reading). + + + + This resource is part of the `v1alpha` API and is subject to change. Fields and behavior may change in future releases. + + +## Identity + +| | | +| --- | --- | +| Group | `compute.datumapis.com` | +| Version | `v1alpha` | +| Kind | `Workload` | +| Scope | Project | + +## Overview + +A `Workload` defines a set of running instances and where they should live. You describe a single instance once in the workload template, then declare one or more placements that control where those instances are deployed (for example, a city or region) and how they scale. Datum Cloud creates and maintains the instances to match this desired state. + +Use a `Workload` when you want to run compute — a container sandbox or a virtual machine — across one or more geographic locations within a Project without managing individual instances by hand. + +## Spec fields + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `spec.placements` | []Object | Yes | Defines where instances should be deployed, and at what scope a deployment lives, such as a city or region. | +| `spec.placements[].name` | string | Yes | The name of the placement. | +| `spec.placements[].cityCodes` | []string | Yes | A list of city codes that define where the instances should be deployed. | +| `spec.placements[].scaleSettings` | Object | Yes | Scale settings such as minimum and maximum replica counts. | +| `spec.placements[].scaleSettings.instanceManagementPolicy` | string | Yes | Controls how instances are managed during scale up and down, as well as during maintenance events. | +| `spec.placements[].scaleSettings.minReplicas` | integer | Yes | The minimum number of replicas. | +| `spec.placements[].scaleSettings.maxReplicas` | integer | No | The maximum number of replicas. | +| `spec.placements[].scaleSettings.metrics` | []Object | No | A list of metrics that determine scaling behavior, such as external metrics. | +| `spec.template` | Object | Yes | Defines settings for each instance. | +| `spec.template.metadata` | Object | No | Metadata of the instances created from this template. | +| `spec.template.spec` | Object | Yes | Describes the desired configuration of an instance. | +| `spec.template.spec.runtime` | Object | Yes | The runtime type of the instance, such as a container sandbox or a VM. | +| `spec.template.spec.runtime.resources` | Object | Yes | Resources each instance must be allocated, including the `instanceType`. | +| `spec.template.spec.runtime.sandbox` | Object | No | A managed isolated environment capable of running containers. | +| `spec.template.spec.runtime.virtualMachine` | Object | No | A classical VM environment, booting a full OS provided via an image. | +| `spec.template.spec.networkInterfaces` | []Object | Yes | Network interface configuration. | +| `spec.template.spec.networkInterfaces[].network` | Object | Yes | The network to attach the interface to. | +| `spec.template.spec.volumes` | []Object | No | Volumes that must be available to attach to an instance's containers or virtual machine. | +| `spec.template.spec.controller` | Object | No | Settings driven by the controller managing the instance. | +| `spec.template.spec.location` | Object | No | The location which the instance has been scheduled to. | + +## Status fields (read-only) + +| Field | Type | Description | +| --- | --- | --- | +| `status.conditions` | []Object | Observations of the workload's current state. Known condition types are `Available` and `Progressing`. | +| `status.replicas` | integer | The number of instances that currently exist. | +| `status.currentReplicas` | integer | The number of instances which have the latest workload settings applied. | +| `status.readyReplicas` | integer | The number of instances which are ready. | +| `status.desiredReplicas` | integer | The desired number of instances. | +| `status.deployments` | integer | The number of deployments that currently exist. | +| `status.placements` | []Object | The current status of placements in a workload. | +| `status.gateway` | Object | The status of the workload gateway, if configured. | + +## Usage + +```yaml +apiVersion: compute.datumapis.com/v1alpha +kind: Workload +metadata: + name: web-frontend +spec: + placements: + - name: us-central + cityCodes: + - DFW + scaleSettings: + instanceManagementPolicy: RollingUpdate + minReplicas: 1 + maxReplicas: 3 + template: + spec: + runtime: + resources: + instanceType: datumcloud/d1-standard-2 + sandbox: + containers: + - name: web + image: registry.example.com/web:latest + networkInterfaces: + - network: + name: default +``` + +```bash +datumctl apply -f workload.yaml --project my-project +datumctl get workloads --project my-project +datumctl describe workload web-frontend --project my-project +``` + + + Run `datumctl explain workloads --recursive` to see the full, live field tree for this resource. + + + diff --git a/api/compute/workloaddeployment.mdx b/api/compute/workloaddeployment.mdx new file mode 100644 index 0000000..3a405ca --- /dev/null +++ b/api/compute/workloaddeployment.mdx @@ -0,0 +1,91 @@ +--- +title: "WorkloadDeployment" +sidebarTitle: "WorkloadDeployment" +description: "WorkloadDeployment is the Schema for the workloaddeployments API." +--- + + + API resource reference for **WorkloadDeployment**, part of the [Compute service](/api/compute/overview). To create or change one, see [Changing resources](/datumctl/resources/changing); to inspect, see [Reading resources](/datumctl/resources/reading). + + + + This resource is part of the `v1alpha1` API and is subject to change. Fields and behavior may change in future releases. + + +## Identity + +| | | +| --- | --- | +| Group | `compute.datumapis.com` | +| Version | `v1alpha1` | +| Kind | `WorkloadDeployment` | +| Scope | Project | + +## Overview + +A `WorkloadDeployment` represents a single placement of a workload scheduled to a specific location, such as a city. Each deployment belongs to a parent workload (referenced by `spec.workloadRef`) and corresponds to one of the workload's placements (`spec.placementName`). It defines how many instances run through its scale settings and what each instance looks like through its instance template. + +You typically do not create `WorkloadDeployment` resources directly — they are produced when a workload is scheduled across its placements. Read them to inspect where a workload has been deployed and how many instances are currently running and ready in a given location. + +## Spec fields + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `spec.cityCode` | string | Yes | The location target for the deployment; deployments can be scheduled in ways other than just a city code. | +| `spec.placementName` | string | Yes | The placement in the workload that is driving this deployment. | +| `spec.workloadRef` | Object | Yes | The workload that this deployment belongs to. | +| `spec.workloadRef.name` | string | Yes | The name of the workload. | +| `spec.workloadRef.uid` | string | Yes | UID of the workload. | +| `spec.scaleSettings` | Object | Yes | Scale settings such as minimum and maximum replica counts. | +| `spec.scaleSettings.instanceManagementPolicy` | string | Yes | Controls how instances are managed during scale up and down, as well as during maintenance events. | +| `spec.scaleSettings.minReplicas` | integer | Yes | The minimum number of replicas. | +| `spec.scaleSettings.maxReplicas` | integer | No | The maximum number of replicas. | +| `spec.scaleSettings.metrics` | []Object | No | A list of metrics that determine scaling behavior, such as external metrics. | +| `spec.template` | Object | Yes | Defines settings for each instance. | +| `spec.template.spec` | Object | Yes | Describes the desired configuration of an instance (runtime, network interfaces, volumes). | +| `spec.template.metadata` | Object | No | Metadata of the instances created from this template. | + +## Status fields (read-only) + +| Field | Type | Description | +| --- | --- | --- | +| `status.conditions` | []Object | Observations of the deployment's current state. Known condition types are `Available` and `Progressing`. | +| `status.location` | Object | The location the deployment has been scheduled to. | +| `status.desiredReplicas` | integer | The desired number of instances. | +| `status.replicas` | integer | The number of instances created. | +| `status.currentReplicas` | integer | The number of instances that have the latest workload settings applied. | +| `status.readyReplicas` | integer | The number of instances that are ready. | + +## Usage + +```yaml +apiVersion: compute.datumapis.com/v1alpha1 +kind: WorkloadDeployment +metadata: + name: web-us-central +spec: + cityCode: DFW + placementName: us-central + workloadRef: + name: web + uid: 4c8f2e1a-9b3d-4f7a-8c21-1e5b7a9d0c3f + scaleSettings: + instanceManagementPolicy: RollingUpdate + minReplicas: 1 + maxReplicas: 3 + template: + spec: + runtime: {} + networkInterfaces: + - {} +``` + +```bash +datumctl apply -f workloaddeployment.yaml --project my-project +datumctl get workloaddeployments --project my-project +datumctl describe workloaddeployment web-us-central --project my-project +``` + + + Run `datumctl explain workloaddeployments --recursive` to see the full, live field tree for this resource. + diff --git a/api/concepts/conventions.mdx b/api/concepts/conventions.mdx new file mode 100644 index 0000000..3caf20a --- /dev/null +++ b/api/concepts/conventions.mdx @@ -0,0 +1,124 @@ +--- +title: "API conventions" +sidebarTitle: "API conventions" +description: "The declarative resource model shared by every Datum Cloud resource: apiVersion, kind, metadata, spec, and status." +--- + +Every Datum Cloud resource — a `DNSZone`, an `HTTPRoute`, a `Project`, a billing account — follows the same shape and the same workflow. Learn it once and it applies to everything in the [API resource reference](/api/overview). + + + This page is the entry point for the API concepts. Once you understand the common shape here, follow the details: [Object metadata](/api/concepts/metadata), [Status & conditions](/api/concepts/status-and-conditions), and [Scopes](/api/concepts/scopes) cover the three top-level sections, while [Field formats & types](/api/concepts/field-formats), [Resource references](/api/concepts/references), [Versioning & stability](/api/concepts/versioning), and [Validation & safe changes](/api/concepts/validation) explain how fields are described, linked, versioned, and checked. + + + + The Datum Cloud API is currently **alpha** (`v1alpha1`). Resources, fields, and defaults may change in backward-incompatible ways between releases. The Gateway API networking resources (for example [`HTTPRoute`](/api/networking/gateway/httproute)) are served at the stable `v1` version. + + +## The declarative model + +Datum Cloud is **declarative**. You don't issue step-by-step commands to build something. Instead, you write down the state you *want* a resource to be in, hand it to the platform, and the platform does the work of making reality match — and keeps it that way. This is the core idea behind every resource: + +- You declare **desired state** (the `spec`). +- The platform **reconciles** continuously, taking whatever actions are needed to reach that state. +- The platform reports **observed state** (the `status`) so you can see what actually happened. + +You describe the destination; the platform figures out the route and tells you where things stand. + +## The top-level shape + +Every resource is an object with the same four top-level fields: + +| Field | Purpose | Who writes it | +| --- | --- | --- | +| `apiVersion` | The API group and version the resource belongs to (`/`). | You | +| `kind` | The type of resource, for example `DNSZone`. | You | +| `metadata` | Identity and bookkeeping — the resource's `name`, labels, annotations, and more. | You (mostly) | +| `spec` | The **desired state** — the fields you set to declare what you want. | You | +| `status` | The **observed state** — what the platform reports back. Read-only. | The platform | + + + A useful way to read any resource: **`spec` is the request, `status` is the receipt.** You own everything in `spec`; the platform owns everything in `status`. Never edit `status` — it's overwritten by the platform on every reconcile. + + +### apiVersion and kind: the resource's identity + +A resource type is identified by three things — its **group**, **version**, and **kind** (often abbreviated GVK): + +- **Group** namespaces related resources together, for example `dns.networking.miloapis.com`. +- **Version** tracks the maturity and shape of the API, for example `v1alpha1`. +- **Kind** is the specific type, for example `DNSZone`. + +The `apiVersion` field combines group and version as `/`, and `kind` names the type. Together they tell the platform exactly which resource you mean: + +```yaml +apiVersion: dns.networking.miloapis.com/v1alpha1 +kind: DNSZone +``` + +Every page in the [API resource reference](/api/overview) opens with an **Identity** table listing the group, version, kind, and scope for that resource. For example, [`DNSZone`](/api/dns/dnszone) is served at group `dns.networking.miloapis.com`, version `v1alpha1`, kind `DNSZone`, scope Project. + +### metadata: naming and organizing + +`metadata` carries the resource's identity and bookkeeping fields — its `name`, any `labels` and `annotations`, and platform-managed values you'll see on resources you read back. See [Object metadata](/api/concepts/metadata) for the full breakdown. + +### spec: what you want + +`spec` is where you declare desired state. The available fields differ by resource type — a `DNSZone` spec names the zone's domain, an `HTTPRoute` spec describes routing rules — but the meaning is always the same: *this is what I want to exist.* Each resource page documents its spec fields, their types, and which are required. + +### status: what actually happened + +`status` is populated by the platform to report observed state. It commonly includes a set of **conditions** — standardized readiness signals such as `Accepted` and `Programmed` — plus resource-specific observed values. Because reconciliation is continuous, `status` is your window into whether the platform has caught up to your `spec` and whether anything went wrong. See [Status & conditions](/api/concepts/status-and-conditions). + +## A generic manifest skeleton + +Strip away the resource-specific fields and every manifest looks like this: + +```yaml +apiVersion: / # e.g. dns.networking.miloapis.com/v1alpha1 +kind: # e.g. DNSZone +metadata: + name: # unique within its scope + labels: # optional: your own key/value tags + example.com/team: platform +spec: + # desired state — the fields you set (resource-specific) +# status is written by the platform; you don't include it when applying +``` + +You write everything above `status`. When you read a resource back, the platform will have added a `status` block (and filled in some managed `metadata`). + +## The desired-state workflow + +Working with any resource is the same loop, regardless of type: + + + + Write a manifest with `apiVersion`, `kind`, `metadata`, and the `spec` you want. You only ever author these. + + + Submit the manifest. The platform stores your desired state and begins reconciling toward it. See [Changing resources](/datumctl/resources/changing) and [Safe changes & declarative config](/datumctl/resources/safe-changes). + + + Controllers take whatever actions are needed to make reality match your `spec`, and keep doing so as conditions change. You don't drive these steps. + + + Inspect `status` (especially its conditions) to confirm the resource is ready, or to see why it isn't. See [Reading resources](/datumctl/resources/reading). + + + + + Because state is declarative, re-applying the same manifest is safe: the platform compares your desired state against what exists and only changes what's different. Keep your manifests in version control and treat them as the source of truth. + + +## Working with resources from the CLI + +The [API resource reference](/api/overview) tells you *what* fields a resource has. The `datumctl` guides tell you *how* to apply and read them — the mechanics are identical for every resource type: + +- [Reading resources](/datumctl/resources/reading) — get and inspect resources and their status. +- [Changing resources](/datumctl/resources/changing) — apply, create, and edit desired state. +- [Safe changes & declarative config](/datumctl/resources/safe-changes) — preview changes and manage manifests declaratively. +- [Output formats & scripting](/datumctl/output-and-scripting) — machine-readable output for automation. +- [Contexts & scoping](/datumctl/contexts-and-scoping) — target the right Project or the Platform. +- [Discovering resources & schemas](/datumctl/discovering-resources) — list available resource types and explore their fields live. + +Because scope (Project vs. Platform) determines where a resource lives and how you address it, read [Scopes](/api/concepts/scopes) alongside [Contexts & scoping](/datumctl/contexts-and-scoping). diff --git a/api/concepts/field-formats.mdx b/api/concepts/field-formats.mdx new file mode 100644 index 0000000..098e084 --- /dev/null +++ b/api/concepts/field-formats.mdx @@ -0,0 +1,117 @@ +--- +title: "Field formats & types" +sidebarTitle: "Field formats & types" +description: "How to read the value types, formats, required markers, enums, and defaults used in every resource's field tables." +--- + + + This is a resource-agnostic guide to the conventions used in the **Spec fields** and **Status fields** tables on every [API resource](/api/overview) page. It explains what the `Type` and `Required` columns mean and how formats are expressed — it does not describe any one resource. For examples, see a real page like [DNSZone](/api/dns/dnszone) or [HTTPRoute](/api/networking/gateway/httproute). + + + + The Datum Cloud API is currently **alpha** (`v1alpha1`; the Gateway API resources are served at stable `v1`). Field types, formats, allowed values, and defaults may change in backward-incompatible ways between releases. + + +## The field tables + +Every resource page lists its fields in two tables: + +- **Spec fields** — the values you set to declare desired state. These have a `Required` column. +- **Status fields** — the values the platform populates to report observed state. These are read-only, so there is no `Required` column. + +Fields are addressed by their dotted path from the top of the object, for example `spec.domainName` or `status.conditions`. A path segment that is itself an object continues with another dot (`spec.rules.matches.path.type`). + +## Value types + +The `Type` column uses a small, consistent vocabulary. + +| Type | Meaning | Example value | +| --- | --- | --- | +| `string` | A single text value. | `"example.com"` | +| `integer` | A whole number. | `3` | +| `boolean` | `true` or `false`. | `true` | +| `[]type` | A **list** of values of `type` (e.g. `[]string`, `[]Object`). | `["ns1.example.net", "ns2.example.net"]` | +| `Object` | A **nested object** with its own fields, documented as deeper rows (`spec.parent.child`). | `{ name: "web", port: 443 }` | +| `map[string]string` | A set of key/value pairs, such as labels or annotations. | `{ env: "prod" }` | + + + A type shown as `Object` or `[]Object` is expanded by its own sub-rows in the same table (or on the same page). To see the complete, live field tree for any resource — including every nested object — run `datumctl explain --recursive`. See [Discovering resources & schemas](/datumctl/discovering-resources). + + +### Lists (`[]type`) + +A `[]type` field accepts zero or more entries. In YAML it is written as a block sequence: + +```yaml +spec: + nameservers: + - ns1.example.net + - ns2.example.net +``` + +`[]Object` lists hold structured entries; each entry has the sub-fields documented for that object. + +### Nested objects + +An `Object` field groups related sub-fields under one key. The field tables document each sub-field on its own row using the full dotted path, so `spec.parent` (type `Object`) is followed by rows like `spec.parent.name` and `spec.parent.port`. + +## Formatted strings + +Some `string` fields carry an additional **format** — a syntax the value must follow. The field's description states the format; common ones include: + +- **RFC 3339 timestamp** — a UTC date-time such as `2026-07-01T14:30:00Z`. All timestamp fields (for example a resource's `metadata.creationTimestamp`) use [RFC 3339](https://www.rfc-editor.org/rfc/rfc3339) form. These are read-only; clients do not set them. +- **RFC 1123 name** — the `metadata.name` of most resources must be a lowercase [RFC 1123](https://www.rfc-editor.org/rfc/rfc1123) label: lowercase alphanumerics and `-`, starting and ending with an alphanumeric (for example `example-com`). +- **RFC 1123 hostname / FQDN** — domain-shaped fields (for example a zone's domain name) use dot-separated RFC 1123 labels, such as `example.com`. +- **Duration** — a Go-style duration string such as `30s`, `5m`, or `1h`. +- **Quantity** — a resource amount such as `500m`, `2Gi`, or `100`. + + + When a field's exact format matters, read its live description with `datumctl explain .` — the schema is the source of truth for the format rules. + + +## How markers are shown + +### Required + +The **`Required`** column marks whether you must supply a spec field. + +| Value | Meaning | +| --- | --- | +| `Yes` | You must set this field for the resource to be valid. | +| _(blank / No)_ | The field is optional. | + +Every resource also requires the standard identifiers (`apiVersion`, `kind`, and `metadata.name`); these are assumed on every page and not repeated in the spec table. + +### Enums (allowed values) + +When a field accepts only a fixed set of values, those values are listed in the field's description. For example, an HTTP route path-match `type` accepts `Exact`, `PathPrefix`, or `RegularExpression` — any other value is rejected on apply. + + + `datumctl explain` surfaces these under an **`ENUM:`** heading, and the API rejects out-of-range values at apply time. + + +### Defaults + +If an optional field is omitted, the platform may apply a **default** value. When a field has a default, the page notes it in the field's description (for example, "defaults to `PathPrefix`"). A field with no documented default is simply left unset when omitted — read the resulting value back from status or with `datumctl get -o yaml`. + +## Reading vs. writing fields + +- **Spec** fields are yours to set. Change them declaratively and re-apply — see [Changing resources](/datumctl/resources/changing) and [Safe changes & declarative config](/datumctl/resources/safe-changes). +- **Status** fields are populated by the platform and are read-only. Inspect them with [Reading resources](/datumctl/resources/reading) and control the shape of the output with [Output formats & scripting](/datumctl/output-and-scripting). + +## Scope: Project vs. Platform + +Each resource's **Identity** table lists a **Scope** of either **Project** (the resource lives inside a project) or **Platform** (it is shared across the platform). Scope determines which context a command runs against — see [Contexts & scoping](/datumctl/contexts-and-scoping). + + + A resource's `metadata` may include a `namespace` field, but you never choose it directly. Datum Cloud scoping is expressed as **Project** or **Platform**; the CLI resolves the underlying `namespace` field from your active context. + + +## Related + +- [API conventions](/api/concepts/conventions) — the `apiVersion`/`kind`/`metadata`/`spec`/`status` model these field tables describe. +- [Object metadata](/api/concepts/metadata) — the shared `metadata` fields, including the `name` format and label/annotation maps. +- [Validation & safe changes](/api/concepts/validation) — how the API enforces these types, formats, enums, and required markers on write. +- [Resource references](/api/concepts/references) — the reference-object convention used by `Ref`/`Refs` fields. +- [Reading resources](/datumctl/resources/reading) and [Output formats & scripting](/datumctl/output-and-scripting) — inspect field values with the CLI. +- [Discovering resources & schemas](/datumctl/discovering-resources) — explore live field types with `datumctl explain`. diff --git a/api/concepts/metadata.mdx b/api/concepts/metadata.mdx new file mode 100644 index 0000000..f7b9913 --- /dev/null +++ b/api/concepts/metadata.mdx @@ -0,0 +1,122 @@ +--- +title: "Object metadata" +sidebarTitle: "Object metadata" +description: "The shared metadata block every Datum Cloud resource carries — name, labels, annotations, and the system-managed fields you never set." +--- + + + This is a resource-agnostic concept page. Every Datum Cloud resource — a [DNSZone](/api/dns/dnszone), an [HTTPRoute](/api/networking/gateway/httproute), a Project, and so on — carries the same `metadata` block, so individual resource pages omit it and link here instead. + + + + The Datum Cloud API is currently **alpha** (`v1alpha1`; the Gateway API resources are served at stable `v1`). Fields and behavior may change in backward-incompatible ways between releases. + + +## Overview + +Every resource you create or read has three top-level sections: `metadata`, `spec`, and `status`. The `spec` and `status` sections are specific to each resource kind, but `metadata` is shared and looks the same everywhere: + +```yaml +apiVersion: dns.networking.miloapis.com/v1alpha1 +kind: DNSZone +metadata: + name: example-com + labels: + team: platform + env: production + annotations: + datum.net/change-ticket: "OPS-1421" +spec: + # ...resource-specific fields +``` + +`metadata` holds the resource's identity (its name), the labels and annotations you use to organize and describe it, and a set of system-managed fields the platform maintains for you. + +## Fields you set + +These are the metadata fields you provide when creating or changing a resource. + +| Field | Type | Description | +| --- | --- | --- | +| `metadata.name` | string | The resource's name. Required at creation (unless the resource supports server-generated names). Must be unique within its scope and **cannot be changed** after creation. | +| `metadata.labels` | map[string]string | Key/value pairs used to organize, group, and select resources. Ideal for querying and filtering. | +| `metadata.annotations` | map[string]string | Key/value pairs for arbitrary, non-identifying metadata — often set by tools or automation. Not used for selection or filtering. | + +### Name + +`name` identifies the resource within its scope. A [Project-scoped](/datumctl/contexts-and-scoping) resource's name must be unique among resources of the same kind in that Project; a Platform-scoped resource's name must be unique across the platform. Names are set once, at creation, and cannot be updated afterward — to "rename" a resource you delete it and create a new one. + +Names follow the standard DNS-compatible naming rules ([RFC 1123](https://datatracker.ietf.org/doc/html/rfc1123)): lowercase alphanumeric characters and `-`, starting and ending with an alphanumeric character (for example, `example-com`). + + + Some resources let the server generate a unique name for you instead of requiring one. When supported, you supply a name prefix and the platform appends a unique suffix. Check a resource's schema with `datumctl explain .metadata` — see [Discovering resources & schemas](/datumctl/discovering-resources). + + +### Labels + +Labels are key/value pairs meant to be **queried and selected on**. Use them to attach identifying dimensions — team ownership, environment, application, tier — that you'll later want to filter by: + +```yaml +metadata: + labels: + team: platform + env: production + app: checkout +``` + +Because labels are indexed for selection, keep the set small and stable, and use them for values you actually filter on. See [Reading resources](/datumctl/resources/reading) and [Output formats & scripting](/datumctl/output-and-scripting) for filtering and label-selector usage. + +### Annotations + +Annotations are also key/value pairs, but they are for **arbitrary metadata that is not queried** — longer descriptions, tool state, change-ticket references, contact info, or data that automation reads and writes. They are not used for selection or filtering, so there's no penalty for larger or more free-form values. + +```yaml +metadata: + annotations: + datum.net/managed-by: "terraform" + datum.net/change-ticket: "OPS-1421" +``` + + + **Labels vs. annotations:** if you want to *find or group* resources by a value, use a label. If you just want to *attach* information to a resource, use an annotation. + + +## Fields the platform manages + +The platform populates and maintains the following fields automatically. They are **read-only** — do not set them in your manifests. They appear when you read a resource (for example with `datumctl get -o yaml`), and are useful for inspection and automation. + +| Field | Type | Description | +| --- | --- | --- | +| `metadata.uid` | string | A globally unique identifier assigned at creation. Unlike `name`, it never changes and is never reused, so it unambiguously identifies one specific instance of a resource over time. | +| `metadata.creationTimestamp` | string | RFC 3339 / UTC timestamp of when the resource was created. | +| `metadata.generation` | integer | A counter that increments each time the resource's `spec` (desired state) changes. Controllers compare it against a resource's observed generation to tell whether the platform has caught up to your latest change. | +| `metadata.resourceVersion` | string | An opaque version token that changes on every update. Used internally for change detection and safe concurrent updates. Treat it as opaque — never edit it. | +| `metadata.deletionTimestamp` | string | Set by the platform when a resource is being deleted. Once set, the resource is scheduled for removal after any outstanding cleanup completes. | +| `metadata.finalizers` | []string | A list of cleanup tasks that must finish before the resource is fully removed. While the list is non-empty, deletion is held so dependent cleanup (releasing addresses, tearing down backing infrastructure) can run. Managed by the platform. | + + + Don't copy these fields into a manifest you're applying. If you save a resource with `datumctl get -o yaml` and re-apply it, strip the system-managed metadata (and the entire `status` block) first — leaving `resourceVersion` in, for example, can cause an apply to be rejected. See [Safe changes & declarative config](/datumctl/resources/safe-changes). + + +## The namespace field + +You may notice a `metadata.namespace` field when you inspect a resource. In Datum Cloud you don't manage namespaces directly — the user-facing scoping concept is the **Project** (or the **Platform**, for shared resources). Your active context determines where a resource lives, and the CLI sets scope with the `--project` flag rather than a namespace field you fill in by hand. See [Contexts & scoping](/datumctl/contexts-and-scoping). + +## Working with metadata + +- **Read it:** `datumctl get -o yaml` shows the full `metadata` block, including the system-managed fields. See [Reading resources](/datumctl/resources/reading). +- **Change it:** set `name`, `labels`, and `annotations` in your manifest and apply with `datumctl apply -f`. See [Changing resources](/datumctl/resources/changing). +- **Explore it:** `datumctl explain .metadata` prints the live schema for the metadata block. See [Discovering resources & schemas](/datumctl/discovering-resources). + + + Run `datumctl explain .metadata --recursive` to see the full, live metadata field tree for any resource. + + +## Related + +- [API conventions](/api/concepts/conventions) — where `metadata` sits in the `apiVersion`/`kind`/`spec`/`status` model. +- [Scopes](/api/concepts/scopes) — why a `name` must be unique within its Project or across the Platform. +- [Status & conditions](/api/concepts/status-and-conditions) — how `metadata.generation` is compared against a condition's `observedGeneration`. +- [Field formats & types](/api/concepts/field-formats) — the RFC 1123 rules for `name` and the map types used by labels and annotations. +- [Reading resources](/datumctl/resources/reading) and [Changing resources](/datumctl/resources/changing) — read and set metadata with the CLI. +- [Contexts & scoping](/datumctl/contexts-and-scoping) — how the CLI resolves the `namespace` field from your active context. diff --git a/api/concepts/references.mdx b/api/concepts/references.mdx new file mode 100644 index 0000000..e079491 --- /dev/null +++ b/api/concepts/references.mdx @@ -0,0 +1,115 @@ +--- +title: "Resource references" +sidebarTitle: "Resource references" +description: "How one Datum Cloud resource points at another through a reference object, and how to follow those links." +--- + +Resources in Datum Cloud rarely stand alone. A route attaches to a gateway, a zone belongs to a domain, an access policy binds a role — and each of those relationships is expressed the same way: with a **reference object**. This page explains that common pattern so you can recognize it on any resource page, regardless of the service. + + + This is a resource-agnostic concept page. For the resources cited as examples, see [DNSZone](/api/dns/dnszone), [HTTPRoute](/api/networking/gateway/httproute), and [SecurityPolicy](/api/networking/envoy/securitypolicy). For how to read and change resources with the CLI, see [Reading resources](/datumctl/resources/reading) and [Changing resources](/datumctl/resources/changing). + + +## The pattern + +A reference is a small object embedded in one resource that identifies another resource. By convention its field name ends in **`Ref`** (a single reference) or **`Refs`** (a list of references). Instead of copying the target's data inline, the referencing resource just names the target and lets the platform resolve the link. + +A reference object typically carries some subset of these keys: + +| Key | Meaning | +| --- | --- | +| `name` | The name of the target resource. Almost always present, and usually required. | +| `kind` | The target's resource type (e.g. `Gateway`, `Role`). Present when a field can point at more than one type. | +| `group` (or `apiGroup`) | The API group the target's kind belongs to. Distinguishes types that share a name across services. | +| `namespace` | The scope the target lives in, when it may differ from the referencing resource's own scope. | + +Simpler references carry only a `name` because the target's type is fixed by the field itself. Broader references — ones that can point at several kinds of resource — add `kind` and `group` so the target is unambiguous. + + + A reference's `namespace` key is the raw metadata field on the target. In Datum Cloud terms, resources are scoped to a **Project** or to the **Platform**; a reference within a Project usually omits `namespace` and resolves to that same Project unless it explicitly points elsewhere. + + +## Where references appear + +References show up in both halves of a resource: + +- In **`spec`**, a reference is part of the desired state *you* declare — you are telling the platform which other resource to relate to. +- In **`status`**, a reference is populated by the platform to report a relationship it *discovered or established* on your behalf. Status references are read-only. + +## Real examples + +The examples below are all confirmed on their resource pages. + +### A fixed-type reference: `DNSZone.status.domainRef` + +A [`DNSZone`](/api/dns/dnszone) reports the [`Domain`](/api/networking/domain) it belongs to through `status.domainRef`. This is a platform-populated (read-only) reference: you create the zone with a domain name, and the platform links it to the managing `Domain` and records that link in status. Because the target is always a `Domain`, the reference needs little more than a name. + +### A multi-target list of references: `HTTPRoute.spec.parentRefs` + +An [`HTTPRoute`](/api/networking/gateway/httproute) attaches to the gateways that serve it through `spec.parentRefs`, a list of reference objects you declare: + +```yaml +spec: + parentRefs: + - name: example-gateway # required + # kind, group, namespace, sectionName, port are optional +``` + +Each entry requires `name` and accepts optional `group`, `kind`, `namespace`, `sectionName`, and `port`. The extra keys exist because a parent is usually — but not always — a `Gateway`; supplying `kind` and `group` disambiguates when it isn't, and `sectionName` narrows the attachment to a specific listener within the parent. The referenced parent must also allow the attachment, so a reference expresses *intent*, not a guarantee. + +### A policy target reference: `SecurityPolicy.spec.targetRefs` + +A [`SecurityPolicy`](/api/networking/envoy/securitypolicy) is not embedded in the gateway it protects — it attaches to one through `spec.targetRefs`: + +```yaml +spec: + targetRefs: + - group: gateway.networking.k8s.io + kind: Gateway + name: my-gateway +``` + +Here `group`, `kind`, and `name` are all required. This is the typical shape for **policy attachment**: a standalone policy resource points at the resource it governs, so you can add, change, or remove the policy without editing the target. (A [`PolicyBinding`](/api/iam/policybinding) uses the same idea for access control, binding a `Role` to subjects through a `roleRef`.) + +## Following a reference + +A reference is a lookup key, not the target's data. To inspect what a reference points at, read the target resource by the name (and, where present, kind and scope) the reference gives you. + +For example, once you have a route's `parentRefs`, you can look up the gateway it names: + +```bash +# See the references on the route +datumctl get httproute example-route -o yaml --project my-project + +# Follow one: read the parent it names +datumctl get gateway example-gateway --project my-project +``` + +The same approach works in reverse: from a `DNSZone` you can follow `status.domainRef` to the `Domain`, and from there see the domain's own status. + + + `datumctl describe` often surfaces related resources and the conditions that report whether a reference resolved successfully — a good first stop when a relationship isn't behaving as expected. + + +## When a reference doesn't resolve + +Because a reference only names a target, the target may be missing, may not permit the relationship, or may live in a scope the referencing resource can't reach. Resources that resolve references generally report the outcome in [`status.conditions`](/api/concepts/status-and-conditions) — for instance, an `HTTPRoute` records a `ResolvedRefs` condition per parent describing whether its backend and parent references resolved. + + + Creating a reference does not create the target. If you point at a resource that doesn't exist yet, the reference stays unresolved until the target appears. Check the referencing resource's conditions to confirm the link was established. + + +## Related + +- [Status & conditions](/api/concepts/status-and-conditions) — how resources report whether a reference resolved (for example a `ResolvedRefs` condition). +- [API conventions](/api/concepts/conventions) — the shared `spec`/`status` model these reference fields live in. +- [Field formats & types](/api/concepts/field-formats) — how `Ref`/`Refs` object fields are described in the field tables. +- [Reading resources](/datumctl/resources/reading) — fetch a resource and the targets its references name. +- [Discovering resources & schemas](/datumctl/discovering-resources) — find which fields on a resource are references, and their types. +- [Changing resources](/datumctl/resources/changing) and [Safe changes & declarative config](/datumctl/resources/safe-changes) — declare and update references safely. +- [Output formats & scripting](/datumctl/output-and-scripting) — extract reference fields for automation. +- [Contexts & scoping](/datumctl/contexts-and-scoping) — how Project and Platform scope affect where a reference resolves. + + + On any resource page, scan the field tables for names ending in `Ref` or `Refs` to see what that resource relates to. You can also explore them live with `datumctl explain --recursive`. + diff --git a/api/concepts/scopes.mdx b/api/concepts/scopes.mdx new file mode 100644 index 0000000..c20d06f --- /dev/null +++ b/api/concepts/scopes.mdx @@ -0,0 +1,106 @@ +--- +title: "Scopes: Project & Platform" +sidebarTitle: "Scopes" +description: "How Datum Cloud resources are scoped to a Project or shared across the Platform, and what that means for your active context and the --project/--organization flags." +--- + + + A concept reference for the **Scope** row you see in every resource page's **Identity** table. To put scoping into practice with the CLI, see [Contexts & scoping](/datumctl/contexts-and-scoping). + + +Every resource in this reference is either **Project-scoped** or **Platform-scoped**. The **Identity** table at the top of each resource page states which one it is: + +| | | +| --- | --- | +| Scope | Project *or* Platform | + +Scope answers two practical questions: **where does this resource live**, and **which context do I need to be in to create, list, or read it**. + +## The two scopes + + + + The resource lives **inside a single Project**. It is created, listed, and read within the context of that Project, and it is isolated from resources in other Projects. + + + The resource is **shared across the platform** — not owned by any one Project. Platform-scoped resources are often read-mostly and provided by Datum. + + + +### Project-scoped resources + +Most resources you create are Project-scoped. They belong to exactly one Project, so two Projects can each have their own resource of the same kind and name without conflict. Listing a Project-scoped kind returns only the resources in the Project you are currently working in. + +Examples of Project-scoped resources: + +- [`DNSZone`](/api/dns/dnszone) — an authoritative DNS zone that lives inside a Project. +- [`HTTPRoute`](/api/networking/gateway/httproute) — routing rules attached to a Gateway within a Project. + + + A resource's `metadata` still carries a `namespace` field, and Project-scoped resources are addressed within a Project. But the user-facing scoping concept in Datum Cloud is simply **Project** — you do not manage or reason about the underlying `namespace` field to use these resources. See [Object metadata](/api/concepts/metadata) for how that field is handled. + + +### Platform-scoped resources + +Platform-scoped resources are shared across the whole platform rather than being owned by a Project. They tend to be **read-mostly** and **provided by Datum** — you reference them from your own Project-scoped resources, but you rarely create or change them yourself. Some Platform-scoped resources (like the organizations and projects that define your account structure) *are* created by you, just not from within a Project. + +Examples of Platform-scoped resources: + +- [`GatewayClass`](/api/networking/gateway/gatewayclass) — a class of Gateways available across the platform. A Project-scoped `Gateway` references a `GatewayClass` by name. +- [`Organization`](/api/resource-manager/organization) and [`Project`](/api/resource-manager/project) — the top-level containers that your Project-scoped resources ultimately live within. + + + When a Project-scoped resource references another resource *by name only* (with no Project attached), that referenced resource is usually Platform-scoped — for example a `Gateway` naming its `GatewayClass`. Check the referenced resource's own Identity table to confirm its scope. + + +## How scope maps to your context + +The CLI always operates in an **active context** — an organization and, for most work, a project. Scope determines which part of that context a resource lives in: + +| Resource scope | Resolved by | What you're working in | +| --- | --- | --- | +| Project | your active **project** | resources inside one Project | +| Platform | your active **organization** / the platform | resources shared across the platform | + +You set the active context once and let subsequent commands inherit it, or you override it per-command with flags: + +- `--project ` — target a specific Project for a Project-scoped resource, regardless of your active context. +- `--organization ` — target a specific organization when resolving Platform-scoped or organization-level resources. + +For the full model — how the active context is chosen, cached, and switched — see [Contexts & scoping](/datumctl/contexts-and-scoping). + + + If you run a command against a Project-scoped resource without an active Project (and without `--project`), the command has nothing to scope to and will not resolve. Set a context or pass `--project`. See [Contexts & scoping](/datumctl/contexts-and-scoping). + + +## What scope means for creating and listing + +**Creating.** When you `apply` or `create` a Project-scoped resource, it is placed in your active Project (or the one named with `--project`). You do not add a Project field to the manifest — the Project comes from your context. Platform-scoped resources are created without a Project; the ones Datum provides you will typically never create at all. + +**Listing.** `datumctl get ` lists Project-scoped resources from your active Project only — switch Projects (or pass `--project`) to see a different Project's resources. For Platform-scoped kinds, `get` returns the platform-wide set that your organization can see. + +```bash +# Project-scoped: lives in, and lists from, one Project +datumctl apply -f dnszone.yaml --project my-project +datumctl get dnszones --project my-project + +# Platform-scoped: shared across the platform, no Project needed +datumctl get gatewayclasses +``` + + + Whether a kind is Project- or Platform-scoped is a property of the resource, not something you choose. Always check the **Identity** table on the resource's own page. + + +## Related guides + +- [Contexts & scoping](/datumctl/contexts-and-scoping) — the active context model and the `--project`/`--organization` flags in depth. +- [Reading resources](/datumctl/resources/reading) — `get` and `describe` across scopes. +- [Changing resources](/datumctl/resources/changing) — creating and editing resources. +- [Safe changes & declarative config](/datumctl/resources/safe-changes) — diffing and dry-running before you write. +- [Discovering resources & schemas](/datumctl/discovering-resources) — find which kinds exist and inspect their fields. +- [Output formats & scripting](/datumctl/output-and-scripting) — machine-readable output for automation. + + + The Datum Cloud API is currently **alpha** (`v1alpha1`; the Gateway API resources are served at the stable `v1`). Resources, fields, and scoping may change in backward-incompatible ways between releases. + diff --git a/api/concepts/status-and-conditions.mdx b/api/concepts/status-and-conditions.mdx new file mode 100644 index 0000000..0713a7b --- /dev/null +++ b/api/concepts/status-and-conditions.mdx @@ -0,0 +1,129 @@ +--- +title: "Status & conditions" +sidebarTitle: "Status & conditions" +description: "How to read a resource's observed state and interpret the standard conditions pattern across Datum Cloud." +--- + + + A concept page for the whole [API reference](/api/overview). Every resource has a `spec` (the desired state you declare) and a `status` (the observed state the platform reports back). This page explains how to read `status` and the shared `conditions` pattern. To actually read a resource, see [Reading resources](/datumctl/resources/reading) and [Output formats & scripting](/datumctl/output-and-scripting). + + + + The Datum Cloud API is currently **alpha** (`v1alpha1`; the Gateway API resources are served at stable `v1`). Status fields, condition types, and reason strings may change in backward-incompatible ways between releases. + + +## Spec vs. status + +Datum Cloud resources separate what you *want* from what the platform *observes*: + +| Section | Who writes it | What it means | +| --- | --- | --- | +| `spec` | You | The desired state you declare. This is the part you edit and apply. | +| `status` | The platform | The observed state, reported back as the platform works toward your `spec`. Read-only. | + +You never set `status` yourself. When you apply a manifest, the platform stores your `spec`, then a controller works to make reality match it and records progress in `status`. Reading `status` is how you answer "did what I asked for actually happen, and is it healthy?" + + + Because `status` is populated asynchronously, a freshly created resource may have an empty or partial `status` for a short time while the platform reconciles it. Re-read the resource to see it converge. + + +## What lives in status + +The exact `status` fields differ per resource, but they fall into two broad kinds: + +- **Observed values** — concrete data the platform discovered or assigned. For example, a [DNSZone](/api/dns/dnszone) reports `status.nameservers` (the active authoritative nameservers) and `status.recordCount`. These are useful outputs you often need downstream. +- **`status.conditions`** — a standardized list describing the resource's health and readiness. This is the same shape on every resource that has it, so once you can read conditions on one resource you can read them on all of them. + +The rest of this page focuses on `conditions`, since it is the common pattern. + +## The conditions pattern + +`status.conditions` is a list of objects. Each entry describes **one aspect** of the resource's current state — for example, whether it was accepted, whether it was programmed into the underlying system, or whether it is fully ready. A resource surfaces several conditions at once, and you read them together to understand its overall state. + +Every condition has the same fields: + +| Field | Type | Description | +| --- | --- | --- | +| `type` | string | The aspect of state this condition describes, in CamelCase (e.g. `Accepted`, `Programmed`, `Ready`). | +| `status` | string | One of `True`, `False`, or `Unknown` — whether that aspect currently holds. | +| `reason` | string | A programmatic, CamelCase identifier for *why* the condition is in its current state. Stable enough to branch on in scripts. | +| `message` | string | A human-readable explanation of the transition. May be empty. | +| `lastTransitionTime` | string | RFC 3339 timestamp of when `status` last changed to its current value. | +| `observedGeneration` | integer | The `metadata.generation` the condition was evaluated against. | + +### Interpreting the status value + +The meaning of `True` and `False` depends on the condition `type` — read them relative to what the type asserts (e.g. "is this Ready?"), not as generic pass/fail: + +- **`True`** — the aspect named by `type` holds. For a positive readiness type like `Ready` or `Accepted`, `True` is the healthy, desired outcome. +- **`False`** — the aspect does not hold. Check `reason` and `message` to find out why. For a readiness type, `False` usually means something needs your attention or is still failing. +- **`Unknown`** — the platform cannot currently determine the state (for example, it hasn't observed the resource yet, or a dependency is itself unknown). Often a transient state right after a change. + + + Read `reason` and `message` together. `reason` is a stable machine-readable code you can match on in automation; `message` is the human explanation of what happened and, often, what to do next. + + +### Checking observedGeneration first + +`metadata.generation` increments each time you change a resource's `spec`. A condition's `observedGeneration` tells you which generation the platform had processed when it set that condition. + + + If `status.conditions[*].observedGeneration` is **less than** the current `metadata.generation`, the condition is stale — it reflects an earlier version of your `spec`, not your latest change. Wait for the platform to catch up before trusting a condition's `status`. A `Ready: True` that describes an old generation does not mean your newest edit succeeded. + + +## Common readiness condition types + +Condition types are defined per resource, so always confirm the exact set for a given resource (see [inspecting the schema](#discovering-a-resources-status-schema)). That said, several types recur across the API, especially on networking and DNS resources: + +| Type | Roughly means | +| --- | --- | +| `Accepted` | The platform validated your `spec` and accepted the request. | +| `Programmed` | The accepted configuration was applied to the underlying system (e.g. the DNS zone or route is live). | +| `Ready` | The resource is fully provisioned and usable. | + +For example, a [DNSZone](/api/dns/dnszone)'s `status.conditions` "tracks state such as Accepted and Programmed readiness," and the Gateway API resources such as [HTTPRoute](/api/networking/gateway/httproute) use `Accepted` and `Programmed` in the same way. A healthy resource typically shows these as `status: True` with a `reason` that echoes the type (for example `Accepted` / `Programmed`). + + + There is no universal, fixed list of condition types. Treat the table above as common conventions, not a guarantee — the authoritative set for any resource comes from its schema and its own reference page. + + +## Inspecting status with the CLI + +Conditions and other status fields are easiest to read with `datumctl`. + +`datumctl describe` renders conditions in a readable block, which is the fastest way to eyeball readiness and reasons: + +```bash +datumctl describe dnszone example-com --project my-project +``` + +`datumctl get -o yaml` prints the full object — use it to see the raw `status`, every condition field, and `observedGeneration`: + +```bash +datumctl get dnszone example-com -o yaml --project my-project +``` + +For scripting, extract a specific condition or field with an output template instead of parsing text. See [Output formats & scripting](/datumctl/output-and-scripting) for JSONPath and Go-template patterns, and [Contexts & scoping](/datumctl/contexts-and-scoping) for selecting the Project or Platform scope you're reading from. + + + When a change doesn't seem to take effect, compare `metadata.generation` against each condition's `observedGeneration` in the `-o yaml` output. If they differ, the platform is still reconciling your latest `spec`. + + +## Discovering a resource's status schema + +Because status fields and condition types vary by resource, inspect the live schema rather than guessing: + +```bash +datumctl explain dnszone.status --recursive +``` + +This lists the exact `status` fields and the `conditions` structure for that resource, straight from the live API. See [Discovering resources & schemas](/datumctl/discovering-resources) for more on exploring the API this way, and [Safe changes & declarative config](/datumctl/resources/safe-changes) for previewing edits before you apply them. + +## Related + +- [API conventions](/api/concepts/conventions) — the `spec`/`status` model this page builds on. +- [Resource references](/api/concepts/references) — status often reports resolved relationships (for example a `ResolvedRefs` condition), and this page explains how to follow them. +- [Object metadata](/api/concepts/metadata) — `metadata.generation`, which conditions compare against via `observedGeneration`. +- [Reading resources](/datumctl/resources/reading) — `get` and `describe` to see status and conditions. +- [Output formats & scripting](/datumctl/output-and-scripting) — extract a specific condition or field for automation. +- [Contexts & scoping](/datumctl/contexts-and-scoping) — select the Project or Platform scope you read status from. diff --git a/api/concepts/validation.mdx b/api/concepts/validation.mdx new file mode 100644 index 0000000..db267ae --- /dev/null +++ b/api/concepts/validation.mdx @@ -0,0 +1,50 @@ +--- +title: "Validation & safe changes" +sidebarTitle: "Validation & safe changes" +description: "How the Datum Cloud API validates resources on write, and how to preview changes before they take effect." +--- + +Every write to the Datum Cloud API is validated before it is accepted. If a resource does not meet the schema, the API rejects the whole request and changes nothing — a rejected write never partially applies. + +## What the API checks + +When you create or update a resource, the API validates the submitted fields against the live schema for that resource's kind. Common checks include: + +- **Required fields** — fields marked *Required* on a resource page must be present. For a [`DNSZone`](/api/dns/dnszone), for example, both `spec.dnsZoneClassName` and `spec.domainName` are required. +- **Enums** — fields that accept a fixed set of values reject anything outside that set. +- **Formats and types** — strings, integers, durations, and formatted values (such as hostnames) must match the expected shape. +- **Cross-field and reference rules** — some resources enforce relationships between fields or that referenced resources exist. + + + The full field list, types, and required markers for each resource come from the live schema. Browse them on the resource pages in this reference, or explore them from the CLI — see [Discovering resources & schemas](/datumctl/discovering-resources). + + +## Preview before you apply + +You don't have to submit a write to find out whether it's valid. The API can run the same validation against a proposed change and report the result without persisting anything. + +- **`datumctl diff -f`** shows what a manifest would change against the current live state. +- **`--dry-run=server`** sends the resource through full server-side validation and admission, then discards it — so you see the exact errors a real write would produce, with nothing committed. + +See [Safe changes & declarative config](/datumctl/resources/safe-changes) for how to combine these into a review-before-apply workflow. + + + Previewing is especially worthwhile for cross-resource changes such as a [`HTTPRoute`](/api/networking/gateway/httproute) that references a gateway — validation surfaces broken references before they reach production. + + +## Machine-readable failures + +For scripts and automation, validation errors can be emitted in a structured form instead of human-readable text. Use `--error-format` to get machine-readable failures you can parse in CI. See [Output formats & scripting](/datumctl/output-and-scripting). + + + The Datum Cloud API is currently **alpha** (`v1alpha1`; the Gateway API resources are served at `v1`). Validation rules, required fields, and defaults may change in backward-incompatible ways between releases. + + +## Related + +- [Safe changes & declarative config](/datumctl/resources/safe-changes) — the review-before-apply workflow with `datumctl diff` and `--dry-run=server`. +- [Output formats & scripting](/datumctl/output-and-scripting) — machine-readable validation failures for CI with `--error-format`. +- [Field formats & types](/api/concepts/field-formats) — the types, formats, enums, and required markers the API enforces here. +- [API conventions](/api/concepts/conventions) — the declarative model behind every write. +- [Resource references](/api/concepts/references) — how cross-resource reference checks behave. +- [Discovering resources & schemas](/datumctl/discovering-resources) — inspect the live schema a write is validated against. diff --git a/api/concepts/versioning.mdx b/api/concepts/versioning.mdx new file mode 100644 index 0000000..131d3dd --- /dev/null +++ b/api/concepts/versioning.mdx @@ -0,0 +1,70 @@ +--- +title: "Versioning & stability" +sidebarTitle: "Versioning & stability" +description: "How Datum Cloud versions its API resources, what alpha means for stability, and how to protect yourself against change." +--- + + + A resource-agnostic concept page. For working with resources through the CLI, see [Reading resources](/datumctl/resources/reading), [Changing resources](/datumctl/resources/changing), and [Discovering resources & schemas](/datumctl/discovering-resources). + + +## The version scheme + +Every resource carries an `apiVersion`, written as `group/version`: + +```yaml +apiVersion: dns.networking.miloapis.com/v1alpha1 +kind: DNSZone +``` + +- **Group** namespaces a family of related resources (for example, `dns.networking.miloapis.com`). +- **Version** identifies which revision of that group's schema you are using (for example, `v1alpha1`). + +The same kind can be served at more than one version over its lifetime. The version you write in a manifest is the version the platform reads and validates against, so it always appears alongside the `kind` on every resource page's **Identity** table. + +## What "alpha" means + +An alpha version — spelled `v1alpha1` (or `v1alpha`) — is an early, evolving revision. Alpha resources are usable and real, but their shape is not yet frozen: + +| You can expect | During alpha | +| --- | --- | +| Fields added, renamed, or removed | Yes | +| Defaults and validation rules changed | Yes | +| Behavior refined between releases | Yes | +| Backward-incompatible changes | Yes, without a version bump | + +In short, alpha is where the resource is still being designed in the open. It is a good place to build and give feedback, but not something to treat as a permanently stable contract. + + + Most Datum Cloud resources are currently **alpha** (`v1alpha1` / `v1alpha`). Fields, defaults, and behavior may change in backward-incompatible ways between releases, and an alpha version can change without changing its name. Don't assume a manifest that applies cleanly today will apply unchanged in a later release. + + +## What's stable today + +The **Gateway API** resources — [Gateway](/api/networking/gateway/gateway), [HTTPRoute](/api/networking/gateway/httproute), and the rest of the `gateway.networking.k8s.io` group — are served at stable `v1`. They follow the open, portable [Gateway API](https://gateway-api.sigs.k8s.io) specification, so their schema is well established and changes conservatively. + +Everything else in this reference is alpha. Check the **Identity** table on any resource page for its group and version; if the version ends in `alpha`, treat it as evolving. + +## Practical advice + + + **Pin the version you use.** Always write an explicit `apiVersion` in your manifests and keep it under version control. Don't rely on a "current" or default version resolving to what you expect later. + + +- **Expect fields to change.** For alpha resources, plan to revisit manifests when you upgrade, and re-read the resource page or run `datumctl explain` after an upgrade rather than assuming the schema held. +- **Check the live schema.** The field types and required markers in this reference come from the live API. Confirm them for your environment with [Discovering resources & schemas](/datumctl/discovering-resources) — for example, `datumctl explain dnszones --recursive`. +- **Make changes safely.** Use server-side dry runs and diffs before writing, especially against alpha resources whose validation may have shifted. See [Safe changes & declarative config](/datumctl/resources/safe-changes). +- **Script defensively.** When you read resource fields in automation, don't over-fit to alpha field names or shapes. See [Output formats & scripting](/datumctl/output-and-scripting). + + + Version is independent of scope. A resource being alpha or stable says nothing about whether it lives in a **Project** or on the **Platform** — that's a separate axis covered under [Scopes](/api/concepts/scopes) and [Contexts & scoping](/datumctl/contexts-and-scoping). + + +## Related + +- [API conventions](/api/concepts/conventions) — where `apiVersion` fits in the shared resource model. +- [Scopes](/api/concepts/scopes) — the Project/Platform axis, independent of version. +- [Field formats & types](/api/concepts/field-formats) — how field types and required markers are described (and why they can shift during alpha). +- [Validation & safe changes](/api/concepts/validation) — dry-run and diff before applying against evolving alpha schemas. +- [Discovering resources & schemas](/datumctl/discovering-resources) — confirm the live version and schema with `datumctl explain`. +- [Safe changes & declarative config](/datumctl/resources/safe-changes) and [Output formats & scripting](/datumctl/output-and-scripting) — apply and script defensively. diff --git a/api/dns/dnsrecordset.mdx b/api/dns/dnsrecordset.mdx new file mode 100644 index 0000000..9ec1553 --- /dev/null +++ b/api/dns/dnsrecordset.mdx @@ -0,0 +1,98 @@ +--- +title: "DNSRecordSet" +sidebarTitle: "DNSRecordSet" +description: "DNSRecordSet is the Schema for the dnsrecordsets API." +--- + + + API resource reference for **DNSRecordSet**, part of the [DNS service](/api/dns/overview). To create or change one, see [Changing resources](/datumctl/resources/changing); to read or inspect, see [Reading resources](/datumctl/resources/reading). For the underlying concept, see [Domains & DNS](/domain-dns/dns). + + + + This resource is part of an **alpha** API (`v1alpha1`). Fields and behavior are subject to change without notice. + + +## Identity + +| | | +| --- | --- | +| Group | `dns.networking.miloapis.com` | +| Version | `v1alpha1` | +| Kind | `DNSRecordSet` | +| Scope | Project | + +## Overview + +A `DNSRecordSet` defines a set of DNS resource records of a single type (for example, `A`, `AAAA`, `CNAME`, or `TXT`) within a DNS zone. Each recordset references the `DNSZone` it belongs to and carries one or more owner names, each with values appropriate for the record type. Use it to publish and manage the DNS records that resolve names in a zone you own. + +## Spec fields + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `spec.dnsZoneRef` | Object | Yes | DNSZoneRef references the DNSZone this recordset belongs to. | +| `spec.dnsZoneRef.name` | string | No | Name of the referent DNSZone. | +| `spec.recordType` | string | Yes | The DNS RR type for this recordset. One of the enum values `A`, `AAAA`, `ALIAS`, `CNAME`, and others. | +| `spec.records` | []Object | Yes | One or more owner names with values appropriate for the RecordType. | +| `spec.records[].name` | string | Yes | The owner name (relative to the zone or FQDN). | +| `spec.records[].ttl` | integer | No | Optionally overrides the TTL for this owner/RRset. | +| `spec.records[].a` | Object | No | Value for an `A` record. Exactly one type-specific field should be set matching RecordType. | +| `spec.records[].a.content` | string | Yes* | The record value. Required when the `a` object is set. | +| `spec.records[].aaaa` | Object | No | Value for an `AAAA` record. | +| `spec.records[].alias` | Object | No | Value for an ALIAS/ANAME-style record; content is a hostname (FQDN or relative) with an optional trailing dot. | +| `spec.records[].caa` | Object | No | Value for a `CAA` record. | +| `spec.records[].cname` | Object | No | Value for a `CNAME` record. | +| `spec.records[].cname.content` | string | Yes* | The record value. Required when the `cname` object is set. | +| `spec.records[].https` | Object | No | Value for an `HTTPS` record. | +| `spec.records[].mx` | Object | No | Value for an `MX` record. | +| `spec.records[].ns` | Object | No | Value for an `NS` record. | +| `spec.records[].ptr` | Object | No | Value for a `PTR` record. | +| `spec.records[].soa` | Object | No | Value for an `SOA` record. | +| `spec.records[].srv` | Object | No | Value for an `SRV` record. | +| `spec.records[].svcb` | Object | No | Value for an `SVCB` record. | +| `spec.records[].tlsa` | Object | No | Value for a `TLSA` record. | +| `spec.records[].txt` | Object | No | Value for a `TXT` record. | +| `spec.records[].txt.content` | string | Yes* | The record value. Required when the `txt` object is set. | + + + Within each entry in `spec.records`, exactly one type-specific object (`a`, `aaaa`, `cname`, `txt`, and so on) should be set, matching `spec.recordType`. Fields marked Yes* are required only when their parent type-specific object is present. + + +## Status fields (read-only) + +| Field | Type | Description | +| --- | --- | --- | +| `status.conditions` | []Object | Includes `Accepted` and `Programmed` readiness. | +| `status.recordSets` | []Object | Captures per-owner (per name) status and conditions. | + +## Usage + +```yaml +apiVersion: dns.networking.miloapis.com/v1alpha1 +kind: DNSRecordSet +metadata: + name: www-a +spec: + dnsZoneRef: + name: example-com + recordType: A + records: + - name: www + ttl: 300 + a: + content: 203.0.113.10 +``` + +```bash +# Apply the recordset +datumctl apply -f dnsrecordset.yaml --project my-project + +# List DNS recordsets in the project +datumctl get dnsrecordsets --project my-project + +# Inspect a specific recordset +datumctl describe dnsrecordset www-a --project my-project +``` + + + Run `datumctl explain dnsrecordsets --recursive` to see the full, live field tree for this resource. + diff --git a/api/dns/dnszone.mdx b/api/dns/dnszone.mdx new file mode 100644 index 0000000..e3e8098 --- /dev/null +++ b/api/dns/dnszone.mdx @@ -0,0 +1,64 @@ +--- +title: "DNSZone" +sidebarTitle: "DNSZone" +description: "DNSZone is the Schema for the dnszones API." +--- + + + API resource reference for **DNSZone**, part of the [DNS service](/api/dns/overview). To create or change one, see [Changing resources](/datumctl/resources/changing); to read or inspect, see [Reading resources](/datumctl/resources/reading). For the underlying concept, see [Domains & DNS](/domain-dns/dns). + + + + This resource is part of the `v1alpha1` API and is subject to change. Fields and behavior may change in future releases. + + +## Identity + +| | | +| --- | --- | +| Group | `dns.networking.miloapis.com` | +| Version | `v1alpha1` | +| Kind | `DNSZone` | +| Scope | Project | + +## Overview + +A `DNSZone` represents an authoritative DNS zone for a fully qualified domain name, provisioned from a referenced `DNSZoneClass`. Use it to establish the zone (for example, `example.com`) that DNS record sets are attached to within a Project. + +## Spec fields + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `spec.dnsZoneClassName` | string | Yes | References the DNSZoneClass used to provision this zone. | +| `spec.domainName` | string | Yes | The FQDN of the zone (e.g., `example.com`). | + +## Status fields (read-only) + +| Field | Type | Description | +| --- | --- | --- | +| `status.conditions` | []Object | Tracks state such as Accepted and Programmed readiness. | +| `status.domainRef` | Object | References the Domain this zone belongs to. | +| `status.nameservers` | []string | Lists the active authoritative nameservers for this zone. | +| `status.recordCount` | integer | The number of DNSRecordSet resources in this Project that reference this zone. | + +## Usage + +```yaml +apiVersion: dns.networking.miloapis.com/v1alpha1 +kind: DNSZone +metadata: + name: example-com +spec: + dnsZoneClassName: standard + domainName: example.com +``` + +```bash +datumctl apply -f dnszone.yaml --project my-project +datumctl get dnszones --project my-project +datumctl describe dnszone example-com --project my-project +``` + + + Run `datumctl explain dnszones --recursive` to see the full, live field tree for this resource. + diff --git a/api/dns/dnszoneclass.mdx b/api/dns/dnszoneclass.mdx new file mode 100644 index 0000000..12cb391 --- /dev/null +++ b/api/dns/dnszoneclass.mdx @@ -0,0 +1,78 @@ +--- +title: "DNSZoneClass" +sidebarTitle: "DNSZoneClass" +description: "DNSZoneClass is the Schema for the dnszoneclasses API." +--- + + + **Platform-provided resource.** Datum operates this resource; you typically reference or read it rather than create it. See [Platform resources](/api/platform/overview). + + + + API resource reference for **DNSZoneClass**. See [Platform resources](/api/platform/overview) for related platform-provided resources. A [DNSZone](/api/dns/dnszone) selects a class through its `spec.dnsZoneClassName`. To read or inspect, see [Reading resources](/datumctl/resources/reading). For the underlying concept, see [Domains & DNS](/domain-dns/dns). + + + + This resource is part of the `v1alpha1` API and is subject to change. Fields and behavior may evolve in future releases. + + +## Identity + +| | | +| --- | --- | +| **Group** | `dns.networking.miloapis.com` | +| **Version** | `v1alpha1` | +| **Kind** | `DNSZoneClass` | +| **Scope** | Platform | + +## Overview + +A `DNSZoneClass` describes a class of DNS zone: which downstream controller or backend implementation serves the zones that reference it, and the default behavior applied to those zones. You define a `DNSZoneClass` once, at the Platform level, so that individual DNS zones can select a backend (for example, `powerdns` or `hickory`) along with default TTLs and a nameserver-assignment policy. + +## Spec fields + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `spec.controllerName` | string | Yes | Identifies the downstream controller/backend implementation (e.g., `powerdns`, `hickory`). | +| `spec.defaults` | Object | No | Provides optional default values applied to managed zones. | +| `spec.defaults.defaultTTL` | integer | No | Default TTL applied to records when not otherwise specified. | +| `spec.nameServerPolicy` | Object | No | Defines how nameservers are assigned for zones using this class. | +| `spec.nameServerPolicy.mode` | string | Yes | Which policy to use. Enum: `Static`. | +| `spec.nameServerPolicy.static` | Object | No | A static list of authoritative nameservers when `mode == "Static"`. | +| `spec.nameServerPolicy.static.servers` | []string | Yes | The authoritative nameservers. | + + + `spec.nameServerPolicy.mode` and `spec.nameServerPolicy.static.servers` are only required when their parent object is present. The single top-level required field is `spec.controllerName`. + + +## Status fields (read-only) + +| Field | Type | Description | +| --- | --- | --- | +| `status.conditions` | []Object | Represent the current state of the resource. Common types include `Accepted` and `Programmed` to standardize readiness reporting across controllers. | + +## Usage + +```yaml +apiVersion: dns.networking.miloapis.com/v1alpha1 +kind: DNSZoneClass +metadata: + name: powerdns +spec: + controllerName: powerdns +``` + +```bash +# Create or update the DNSZoneClass +datumctl apply -f dnszoneclass.yaml + +# List all DNSZoneClasses +datumctl get dnszoneclasses + +# Inspect a single DNSZoneClass +datumctl describe dnszoneclass powerdns +``` + + + Run `datumctl explain dnszoneclasses --recursive` to see the full, live field tree for this resource. + diff --git a/api/dns/overview.mdx b/api/dns/overview.mdx new file mode 100644 index 0000000..ab9d4a1 --- /dev/null +++ b/api/dns/overview.mdx @@ -0,0 +1,40 @@ +--- +title: "DNS" +sidebarTitle: "Overview" +description: "Managed authoritative DNS on Datum Cloud — zones and the record sets that answer queries for them." +--- + +Datum Cloud provides managed authoritative DNS through the `dns.networking.miloapis.com` API. You declare a zone for a domain you control, add the record sets that answer queries for it, and Datum handles provisioning the zone on a backend, assigning nameservers, and publishing your records. Zones and record sets are Project resources you create with `datumctl apply -f`; a Platform-level zone class selects the backend controller and supplies provisioning defaults. + + + The DNS API is **alpha** (`v1alpha1`). Fields and behavior may change in backward-incompatible ways between releases. + + +## Resources + + + + A managed zone for a domain (for example `example.com`). Binds a domain name to a zone class and reports its active nameservers. + + + One or more records of a single type (A, AAAA, CNAME, and more) attached to a zone. + + + +**Platform-provided:** the [DNSZoneClass](/api/dns/dnszoneclass) referenced by a zone lives under [Platform resources](/api/platform/overview). + +## How the pieces fit together + +- A **DNSZone** references a **DNSZoneClass** by name (`spec.dnsZoneClassName`) and declares the fully qualified `spec.domainName`. Once accepted, its status reports the authoritative `nameservers` you delegate to and a `recordCount`. +- A **DNSRecordSet** references its **DNSZone** (`spec.dnsZoneRef`), sets a `spec.recordType`, and carries one or more `spec.records`. Its status tracks per-owner readiness. + + + Inspect the exact fields for any resource with `datumctl explain`, for example `datumctl explain dnszones.spec` or `datumctl explain dnsrecordsets.spec`. + + +## Learn more + +- [API resources overview](/api/overview) — the resource reference landing page across all Datum Cloud services. +- [Domains & DNS](/domain-dns/dns) — concepts behind managing domains and DNS on Datum Cloud. +- [Changing resources](/datumctl/resources/changing) — how to apply, edit, and safely preview changes to these resources. +- [Reading resources](/datumctl/resources/reading) — how to list, get, and inspect these resources with `datumctl`. diff --git a/api/iam/group.mdx b/api/iam/group.mdx new file mode 100644 index 0000000..c6b490b --- /dev/null +++ b/api/iam/group.mdx @@ -0,0 +1,57 @@ +--- +title: "Group" +sidebarTitle: "Group" +description: "Group is the Schema for the groups API." +--- + + + API resource reference for **Group**, part of the [IAM service](/api/iam/overview). To create or change one, see [Changing resources](/datumctl/resources/changing); to inspect, see [Reading resources](/datumctl/resources/reading). + + + + This resource is part of the `v1alpha1` API and is subject to change. Fields and behavior may change in future releases. + + +## Identity + +| | | +| --- | --- | +| Group | `iam.miloapis.com` | +| Version | `v1alpha1` | +| Kind | `Group` | +| Scope | Project | + +## Overview + +A `Group` is a named collection of members used to organize access control within a Project. Instead of granting permissions to each member individually, you create a `Group` and reference it when assigning roles, so a set of people can be managed together. + +A `Group` is identified entirely by its `metadata.name` — it has no spec fields. Membership and role assignments are established through other IAM resources that reference the group by name. + +## Spec fields + +This resource has no `spec`. A `Group` is defined solely by its `metadata.name`; there are no configurable spec fields. + +## Status fields (read-only) + +| Field | Type | Description | +| --- | --- | --- | +| `status.conditions` | []Object | Latest available observations of the group's current state. Each entry includes `type`, `status` (`True`/`False`/`Unknown`), `reason`, `message`, `lastTransitionTime`, and `observedGeneration`. | + +## Usage + +```yaml +apiVersion: iam.miloapis.com/v1alpha1 +kind: Group +metadata: + name: platform-admins +``` + +```bash +datumctl apply -f group.yaml --project my-project +datumctl get groups.iam.miloapis.com --project my-project +datumctl describe groups.iam.miloapis.com platform-admins --project my-project +``` + + + Run `datumctl explain groups.iam.miloapis.com --recursive` to see the full, live field tree for this resource. + diff --git a/api/iam/groupmembership.mdx b/api/iam/groupmembership.mdx new file mode 100644 index 0000000..dd400e3 --- /dev/null +++ b/api/iam/groupmembership.mdx @@ -0,0 +1,67 @@ +--- +title: "GroupMembership" +sidebarTitle: "GroupMembership" +description: "GroupMembership is the Schema for the groupmemberships API." +--- + + + API resource reference for **GroupMembership**, part of the [IAM service](/api/iam/overview). To create or change one, see [Changing resources](/datumctl/resources/changing); to inspect, see [Reading resources](/datumctl/resources/reading). + + + + This resource is part of the `v1alpha1` API and is subject to change. Fields and behavior may change in future releases. + + +## Identity + +| | | +| --- | --- | +| Group | `iam.miloapis.com` | +| Version | `v1alpha1` | +| Kind | `GroupMembership` | +| Scope | Project | + +## Overview + +A `GroupMembership` connects a single user to a single group. Use it to add a user as a member of a group so that any roles bound to that group apply to the user. Each membership represents one user-in-group relationship, so you create one `GroupMembership` per user you want to add to a group. + +## Spec fields + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `spec.groupRef` | Object | Yes | Reference to the group the user is being added to. | +| `spec.groupRef.name` | string | Yes | Name of the group being referenced. | +| `spec.groupRef.namespace` | string | Yes | Namespace of the referenced group. | +| `spec.userRef` | Object | Yes | Reference to the user that becomes a member of the group. | +| `spec.userRef.name` | string | Yes | Name of the user being referenced. | + +## Status fields (read-only) + +| Field | Type | Description | +| --- | --- | --- | +| `status.conditions` | []Object | Latest available observations of the membership's current state. | + +## Usage + +```yaml +apiVersion: iam.miloapis.com/v1alpha1 +kind: GroupMembership +metadata: + name: alice-in-platform-admins +spec: + groupRef: + name: platform-admins + namespace: my-project + userRef: + name: alice +``` + +```bash +datumctl apply -f groupmembership.yaml --project my-project +datumctl get groupmemberships.iam.miloapis.com --project my-project +datumctl describe groupmemberships.iam.miloapis.com alice-in-platform-admins --project my-project +``` + + + Run `datumctl explain groupmemberships.iam.miloapis.com --recursive` to see the full, live field tree for this resource. + diff --git a/api/iam/overview.mdx b/api/iam/overview.mdx new file mode 100644 index 0000000..4d17392 --- /dev/null +++ b/api/iam/overview.mdx @@ -0,0 +1,39 @@ +--- +title: "IAM" +sidebarTitle: "Overview" +description: "Identity and access management on Datum Cloud — roles, policy bindings, groups, and service accounts that control who can do what." +--- + +Datum Cloud provides identity and access management through the `iam.miloapis.com` API. You define **roles** that bundle permissions, grant them to identities with **policy bindings**, organize people into **groups**, run automation under **service accounts**, and bring new people onboard with **user invitations**. Together these resources decide which identities can perform which actions on which resources. + + + The IAM API is **alpha** (`v1alpha1`). Fields and behavior may change in backward-incompatible ways between releases. + + +## Resources + + + + A named collection of permissions that can be granted to identities. + + + Grants a role to one or more identities on a target resource. + + + A named set of members you can grant access to as a unit. + + + Places a user or service account into a group. + + + A non-human identity for automation and machine-to-machine access. + + + Invites a person to join and take on access within Datum Cloud. + + + +## Learn more + +- [API resources overview](/api/overview) — the resource reference landing page across all Datum Cloud services. +- [Changing resources](/datumctl/resources/changing) — how to apply, edit, and safely preview changes to these resources. diff --git a/api/iam/policybinding.mdx b/api/iam/policybinding.mdx new file mode 100644 index 0000000..199099d --- /dev/null +++ b/api/iam/policybinding.mdx @@ -0,0 +1,85 @@ +--- +title: "PolicyBinding" +sidebarTitle: "PolicyBinding" +description: "PolicyBinding is the Schema for the policybindings API." +--- + + + API resource reference for **PolicyBinding**, part of the [IAM service](/api/iam/overview). To create or change one, see [Changing resources](/datumctl/resources/changing); to inspect, see [Reading resources](/datumctl/resources/reading). + + + + This resource is part of the `v1alpha1` API and is subject to change. Fields and behavior may change in future releases. + + +## Identity + +| | | +| --- | --- | +| Group | `iam.miloapis.com` | +| Version | `v1alpha1` | +| Kind | `PolicyBinding` | +| Scope | Project | + +## Overview + +A `PolicyBinding` grants access by binding a `Role` to one or more subjects (users, groups, or service accounts) for a specific set of resources. Use it to control who can act on what within a Project: you pick the role that defines the permissions, list the subjects that receive them, and select the resources the role applies to. + +## Spec fields + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `spec.roleRef` | Object | Yes | Reference to the Role being bound. | +| `spec.roleRef.name` | string | Yes | Name of the referenced Role. | +| `spec.roleRef.namespace` | string | No | Namespace of the referenced Role. If empty, the PolicyBinding's own scope is assumed. | +| `spec.subjects` | []Object | Yes | The identities the role applies to. | +| `spec.subjects[].kind` | string | Yes | Type of subject. One of `User`, `Group`, or `ServiceAccount`. | +| `spec.subjects[].name` | string | Yes | Name of the subject. The special group name `system:authenticated-users` refers to all authenticated users. | +| `spec.subjects[].namespace` | string | No | Scope of the subject. Ignored for Users, Groups, and ServiceAccounts when not specified. | +| `spec.subjects[].uid` | string | No | Unique identifier of the subject. Optional for `system:` groups. | +| `spec.resourceSelector` | Object | Yes | Selects which resources the role applies to. `resourceKind` and `resourceRef` are mutually exclusive. | +| `spec.resourceSelector.resourceKind` | Object | No | Apply the role to all resources of a specific kind. | +| `spec.resourceSelector.resourceKind.kind` | string | Yes | The resource type being referenced. | +| `spec.resourceSelector.resourceKind.apiGroup` | string | No | API group of the resource type. If omitted, the kind must be in the core API group. | +| `spec.resourceSelector.resourceRef` | Object | No | Apply the role to a single, specific resource instance. | +| `spec.resourceSelector.resourceRef.kind` | string | Yes | The resource type being referenced. | +| `spec.resourceSelector.resourceRef.name` | string | Yes | Name of the resource being referenced. | +| `spec.resourceSelector.resourceRef.uid` | string | Yes | Unique identifier of the resource being referenced. | +| `spec.resourceSelector.resourceRef.apiGroup` | string | No | API group of the resource. Required for third-party types; if omitted, the kind must be in the core API group. | +| `spec.resourceSelector.resourceRef.namespace` | string | No | Scope of the resource. Required for Project-scoped resources; omitted for Platform-scoped resources. | + +## Status fields (read-only) + +| Field | Type | Description | +| --- | --- | --- | +| `status.conditions` | []Object | Conditions representing the current status of the PolicyBinding. | +| `status.observedGeneration` | integer | The most recent generation observed for this PolicyBinding by the controller. | + +## Usage + +```yaml +apiVersion: iam.miloapis.com/v1alpha1 +kind: PolicyBinding +metadata: + name: dns-editors +spec: + roleRef: + name: dns-editor + subjects: + - kind: User + name: alice@example.com + resourceSelector: + resourceKind: + apiGroup: dns.networking.miloapis.com + kind: DNSZone +``` + +```bash +datumctl apply -f policybinding.yaml --project my-project +datumctl get policybindings.iam.miloapis.com --project my-project +datumctl describe policybindings.iam.miloapis.com dns-editors --project my-project +``` + + + Run `datumctl explain policybindings.iam.miloapis.com --recursive` to see the full, live field tree for this resource. + diff --git a/api/iam/role.mdx b/api/iam/role.mdx new file mode 100644 index 0000000..0575d7d --- /dev/null +++ b/api/iam/role.mdx @@ -0,0 +1,70 @@ +--- +title: "Role" +sidebarTitle: "Role" +description: "Role is the Schema for the roles API." +--- + + + API resource reference for **Role**, part of the [IAM service](/api/iam/overview). To create or change one, see [Changing resources](/datumctl/resources/changing); to inspect, see [Reading resources](/datumctl/resources/reading). + + + + This resource is part of the `v1alpha1` API and is subject to change. Fields and behavior may change in future releases. + + +## Identity + +| | | +| --- | --- | +| Group | `iam.miloapis.com` | +| Version | `v1alpha1` | +| Kind | `Role` | +| Scope | Project | + +## Overview + +A `Role` is a named collection of permissions that can be granted to users, groups, or machine accounts through an IAM policy. Each permission follows the `{service}.{resource}.{action}` format (for example, `compute.workloads.create`). Use a Role to bundle the permissions a person or system needs, then bind that Role in a policy to grant access within a Project. Roles can also inherit permissions from other roles, so you can compose broader roles from narrower ones. + +## Spec fields + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `spec.launchStage` | string | Yes | The launch stage of the role. One of `Early Access`, `Alpha`, `Beta`, `Stable`, or `Deprecated`. | +| `spec.includedPermissions` | []string | No | The names of the permissions this role grants, each in `{service}.{resource}.{action}` format (e.g., `compute.workloads.create`). | +| `spec.inheritedRoles` | []Object | No | The list of roles from which this role inherits permissions. | +| `spec.inheritedRoles[].name` | string | Yes | Name of the referenced Role. | +| `spec.inheritedRoles[].namespace` | string | No | Namespace of the referenced Role. Defaults to the namespace of the resource containing this reference. | + +## Status fields (read-only) + +| Field | Type | Description | +| --- | --- | --- | +| `status.effectivePermissions` | []string | The complete flattened list of all permissions granted by this role, including those from `inheritedRoles` and `includedPermissions`. Computed by the controller. | +| `status.parent` | string | The resource name of the parent the role was created under. | +| `status.conditions` | []Object | Conditions representing the current status of the role. | +| `status.observedGeneration` | integer | The most recent generation observed by the controller. | + +## Usage + +```yaml +apiVersion: iam.miloapis.com/v1alpha1 +kind: Role +metadata: + name: workload-editor +spec: + launchStage: Alpha + includedPermissions: + - compute.workloads.create + - compute.workloads.update + - compute.workloads.get +``` + +```bash +datumctl apply -f role.yaml --project my-project +datumctl get roles.iam.miloapis.com --project my-project +datumctl describe roles.iam.miloapis.com workload-editor --project my-project +``` + + + Run `datumctl explain roles.iam.miloapis.com --recursive` to see the full, live field tree for this resource. + diff --git a/api/iam/serviceaccount.mdx b/api/iam/serviceaccount.mdx new file mode 100644 index 0000000..7d56b41 --- /dev/null +++ b/api/iam/serviceaccount.mdx @@ -0,0 +1,61 @@ +--- +title: "ServiceAccount" +sidebarTitle: "ServiceAccount" +description: "ServiceAccount is the Schema for the service accounts API." +--- + + + API resource reference for **ServiceAccount**, part of the [IAM service](/api/iam/overview). To create or change one, see [Changing resources](/datumctl/resources/changing); to inspect, see [Reading resources](/datumctl/resources/reading). + + + + This resource is part of the `v1alpha1` API and is subject to change. Fields and behavior may change in future releases. + + +## Identity + +| | | +| --- | --- | +| Group | `iam.miloapis.com` | +| Version | `v1alpha1` | +| Kind | `ServiceAccount` | +| Scope | Platform | + +## Overview + +A `ServiceAccount` represents a non-human identity that can authenticate to Datum Cloud, for use by automation, CI pipelines, and other machine-to-machine workloads. Once created, the platform computes a stable email address for the identity, and you control whether it can authenticate by setting its `state`. Set the state to `Inactive` to immediately prohibit new authentication and revoke existing sessions, then back to `Active` to restore access. + +## Spec fields + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `spec.state` | string | No | The activation state of the service account, one of `Active` or `Inactive`. `Active` allows the service account to authenticate; `Inactive` prohibits authentication and revokes all existing sessions. This state can be safely changed as needed. | + +## Status fields (read-only) + +| Field | Type | Description | +| --- | --- | --- | +| `status.conditions` | []Object | Conditions that represent the current status of the ServiceAccount. | +| `status.email` | string | The computed email of the service account, following the pattern `{name}@{namespace}.{project}.{global-suffix}`. | +| `status.state` | string | The current activation state (`Active` or `Inactive`) as observed from the auth provider. Tracks the state from the previous generation and is updated once a state change is successfully propagated. | + +## Usage + +```yaml +apiVersion: iam.miloapis.com/v1alpha1 +kind: ServiceAccount +metadata: + name: ci-deployer +spec: + state: Active +``` + +```bash +datumctl apply -f serviceaccount.yaml +datumctl get serviceaccounts.iam.miloapis.com +datumctl describe serviceaccounts.iam.miloapis.com ci-deployer +``` + + + Run `datumctl explain serviceaccounts.iam.miloapis.com --recursive` to see the full, live field tree for this resource. + diff --git a/api/iam/userinvitation.mdx b/api/iam/userinvitation.mdx new file mode 100644 index 0000000..9fc7171 --- /dev/null +++ b/api/iam/userinvitation.mdx @@ -0,0 +1,80 @@ +--- +title: "UserInvitation" +sidebarTitle: "UserInvitation" +description: "UserInvitation is the Schema for the userinvitations API." +--- + + + API resource reference for **UserInvitation**, part of the [IAM service](/api/iam/overview). To create or change one, see [Changing resources](/datumctl/resources/changing); to inspect, see [Reading resources](/datumctl/resources/reading). + + + + This resource is part of the `v1alpha1` API and is subject to change. Fields and behavior may change in future releases. + + +## Identity + +| | | +| --- | --- | +| Group | `iam.miloapis.com` | +| Version | `v1alpha1` | +| Kind | `UserInvitation` | +| Scope | Project | + +## Overview + +A `UserInvitation` invites a person to join an Organization and grants them one or more roles once they accept. Use it to bring a new member into a Datum Cloud Organization: you supply the invitee's email (and optionally their name), the Organization they are joining, and the roles they will receive. The invited user accepts by setting the invitation's `state` to `Accepted`, at which point the roles take effect. Invitations can also be `Declined` and may carry an expiration date after which they are no longer valid. + +## Spec fields + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `spec.email` | string | Yes | The email of the user being invited. | +| `spec.state` | string | Yes | The state of the invitation. One of `Pending`, `Accepted`, or `Declined`. The invited user sets this to `Accepted` to accept the invitation. | +| `spec.organizationRef` | Object | Yes | Reference to the Organization the user is invited to. | +| `spec.organizationRef.name` | string | Yes | Name of the referenced Organization. | +| `spec.roles` | []Object | Yes | The roles assigned to the user when they accept the invitation. | +| `spec.roles[].name` | string | Yes | Name of the referenced Role. | +| `spec.roles[].namespace` | string | No | Namespace of the referenced Role. If empty, the Role is assumed to be in the same location as the invitation. | +| `spec.givenName` | string | No | The first name of the user being invited. | +| `spec.familyName` | string | No | The last name of the user being invited. | +| `spec.expirationDate` | string | No | The date and time when the invitation expires. If not specified, the invitation never expires. | +| `spec.invitedBy` | Object | No | Reference to the user who issued the invitation. A mutation webhook defaults this to the user who made the request. | +| `spec.invitedBy.name` | string | No | Name of the referenced inviting User. | + +## Status fields (read-only) + +| Field | Type | Description | +| --- | --- | --- | +| `status.conditions` | []Object | Conditions representing the current status of the invitation. | +| `status.inviteeUser` | Object | Information about the invitee user. May be empty if the invitee user has not been created yet. | +| `status.inviterUser` | Object | Information about the user who issued the invitation. | +| `status.organization` | Object | Information about the Organization named in the invitation. | + +## Usage + +```yaml +apiVersion: iam.miloapis.com/v1alpha1 +kind: UserInvitation +metadata: + name: invite-jane-doe +spec: + email: jane.doe@example.com + givenName: Jane + familyName: Doe + state: Pending + organizationRef: + name: acme-corp + roles: + - name: organization-viewer +``` + +```bash +datumctl apply -f userinvitation.yaml --project my-project +datumctl get userinvitations.iam.miloapis.com --project my-project +datumctl describe userinvitations.iam.miloapis.com invite-jane-doe --project my-project +``` + + + Run `datumctl explain userinvitations.iam.miloapis.com --recursive` to see the full, live field tree for this resource. + diff --git a/api/ipam/ipallocation.mdx b/api/ipam/ipallocation.mdx new file mode 100644 index 0000000..c97ea31 --- /dev/null +++ b/api/ipam/ipallocation.mdx @@ -0,0 +1,65 @@ +--- +title: "IPAllocation" +sidebarTitle: "IPAllocation" +description: "IPAllocation records a CIDR carved out of an IPPool by an IPClaim." +--- + + + API resource reference for **IPAllocation**, part of the [IPAM service](/api/ipam/overview). To create or change one, see [Changing resources](/datumctl/resources/changing); to inspect, see [Reading resources](/datumctl/resources/reading). + + + + This resource is part of the `v1alpha1` API and is subject to change. Fields and behavior may change in future releases. + + +## Identity + +| | | +| --- | --- | +| Group | `ipam.miloapis.com` | +| Version | `v1alpha1` | +| Kind | `IPAllocation` | +| Scope | Project | + +## Overview + +An `IPAllocation` records a specific CIDR block that has been carved out of an IPPool to satisfy an IPClaim. It ties a requested IP family to a source pool and, once satisfied, reports the exact CIDR that was allocated. Use it within a Project to track and inspect the address ranges handed out from your IP pools. + +## Spec fields + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `spec.ipFamily` | string | Yes | The IP family requested for the allocation (for example, `IPv4` or `IPv6`). | +| `spec.poolRef` | Object | Yes | References the IPPool the CIDR is allocated from. | +| `spec.poolRef.name` | string | Yes | Name of the referenced IPPool in the same Project. | + +## Status fields (read-only) + +| Field | Type | Description | +| --- | --- | --- | +| `status.allocatedCIDR` | string | The CIDR block that was allocated from the referenced pool. | +| `status.conditions` | []Object | Tracks the state and readiness of the allocation. | +| `status.phase` | string | The current lifecycle phase of the allocation. | + +## Usage + +```yaml +apiVersion: ipam.miloapis.com/v1alpha1 +kind: IPAllocation +metadata: + name: web-tier-allocation +spec: + ipFamily: IPv4 + poolRef: + name: web-tier-pool +``` + +```bash +datumctl apply -f ipallocation.yaml --project my-project +datumctl get ipallocations --project my-project +datumctl describe ipallocation web-tier-allocation --project my-project +``` + + + Run `datumctl explain ipallocations --recursive` to see the full, live field tree for this resource. + diff --git a/api/ipam/ipclaim.mdx b/api/ipam/ipclaim.mdx new file mode 100644 index 0000000..47c8852 --- /dev/null +++ b/api/ipam/ipclaim.mdx @@ -0,0 +1,71 @@ +--- +title: "IPClaim" +sidebarTitle: "IPClaim" +description: "IPClaim requests a sub-prefix of IP address space from an IP pool." +--- + + + API resource reference for **IPClaim**, part of the [IPAM service](/api/ipam/overview). To create or change one, see [Changing resources](/datumctl/resources/changing); to inspect, see [Reading resources](/datumctl/resources/reading). + + + + This resource is part of the `v1alpha1` API and is subject to change. Fields and behavior may change in future releases. + + +## Identity + +| | | +| --- | --- | +| Group | `ipam.miloapis.com` | +| Version | `v1alpha1` | +| Kind | `IPClaim` | +| Scope | Project | + +## Overview + +An `IPClaim` requests a block of IP address space of a given size from an IP pool. You specify the address family (IPv4 or IPv6) and the prefix length you need, and identify the pool to carve the prefix from — either by direct reference or by matching pool labels. Once satisfied, the assigned CIDR is reported back on the claim's status. Use it when a workload or downstream resource needs its own dedicated slice of addresses managed within a Project. + +## Spec fields + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `spec.ipFamily` | string | Yes | The address family for the requested prefix (for example, `IPv4` or `IPv6`). | +| `spec.prefixLength` | integer | Yes | The requested sub-prefix size in bits. Must be a valid mask length for the chosen `ipFamily` (0-32 for IPv4, 0-128 for IPv6). | +| `spec.poolRef` | Object | No | References a specific pool to claim from by name. Set `poolRef.name`; an optional `poolRef.projectRef` points at a pool in another Project. | +| `spec.poolSelector` | Object | No | Selects a parent pool by labels via `matchLabels` / `matchExpressions`, optionally scoped to a specific Project with `poolSelector.projectRef` for shared pools. | +| `spec.ownerRef` | Object | No | An opaque cross-API reference to the object that owns this claim (`apiGroup`, `kind`, `name`, and optional `namespace`). | +| `spec.reclaimPolicy` | string | No | Controls what happens to the allocated prefix when the claim is released. | + +## Status fields (read-only) + +| Field | Type | Description | +| --- | --- | --- | +| `status.allocatedCIDR` | string | The CIDR block that was assigned to satisfy this claim. | +| `status.boundAllocationRef` | Object | References the allocation object (by name) that backs this claim in the same scope. | +| `status.phase` | string | The current lifecycle phase of the claim. | +| `status.conditions` | []Object | Tracks state and readiness for the claim. | + +## Usage + +```yaml +apiVersion: ipam.miloapis.com/v1alpha1 +kind: IPClaim +metadata: + name: web-tier-v4 +spec: + ipFamily: IPv4 + prefixLength: 24 + poolSelector: + matchLabels: + tier: web +``` + +```bash +datumctl apply -f ipclaim.yaml --project my-project +datumctl get ipclaims --project my-project +datumctl describe ipclaim web-tier-v4 --project my-project +``` + + + Run `datumctl explain ipclaims --recursive` to see the full, live field tree for this resource. + diff --git a/api/ipam/ippool.mdx b/api/ipam/ippool.mdx new file mode 100644 index 0000000..fdc5589 --- /dev/null +++ b/api/ipam/ippool.mdx @@ -0,0 +1,82 @@ +--- +title: "IPPool" +sidebarTitle: "IPPool" +description: "IPPool is an allocatable address space. Root pools declare a CIDR directly; child pools carve a sub-prefix from a parent pool." +--- + + + **Platform-provided resource.** Datum operates this resource; you typically reference or read it rather than create it. See [Platform resources](/api/platform/overview). + + + + API resource reference for **IPPool**. See [Platform resources](/api/platform/overview) for related platform-provided resources. An [IPClaim](/api/ipam/ipclaim) allocates addresses from a pool. To read or inspect, see [Reading resources](/datumctl/resources/reading). + + + + This resource is part of the `v1alpha1` API and is subject to change. Fields and behavior may change in future releases. + + +## Identity + +| | | +| --- | --- | +| Group | `ipam.miloapis.com` | +| Version | `v1alpha1` | +| Kind | `IPPool` | +| Scope | Platform | + +## Overview + +An `IPPool` is an allocatable address space that IP address management (IPAM) draws from. A **root pool** declares its address range directly with a CIDR, while a **child pool** carves a smaller sub-prefix out of a parent pool by referencing it. Use an `IPPool` to define and hierarchically subdivide the address space that networking resources allocate addresses from, and read its status to track remaining headroom and utilization. + +## Spec fields + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `spec.cidr` | string | No | The address range for a root pool, in CIDR notation (for example, `10.0.0.0/16`). Root pools declare a CIDR directly. | +| `spec.ipFamily` | string | No | The address family of the pool (for example, IPv4 or IPv6). | +| `spec.prefixLength` | integer | No | The prefix length to carve when this pool is derived from a parent pool. | +| `spec.parentPoolRef` | Object | No | References the parent `IPPool` (in the same scope) that a child pool carves its sub-prefix from. | +| `spec.parentPoolRef.name` | string | Yes* | Name of the referenced parent pool. Required when `parentPoolRef` is set. | +| `spec.visibility` | string | No | Controls the visibility of the pool. | +| `spec.allocation` | Object | No | Configures sub-allocation behavior for the pool. | +| `spec.allocation.strategy` | string | No | The strategy used when allocating sub-prefixes from this pool. | +| `spec.allocation.minPrefixLength` | integer | No | The smallest prefix length (largest block) that may be allocated from this pool. | +| `spec.allocation.maxPrefixLength` | integer | No | The largest prefix length (smallest block) that may be allocated from this pool. | + +## Status fields (read-only) + +| Field | Type | Description | +| --- | --- | --- | +| `status.phase` | string | The current lifecycle phase of the pool. | +| `status.conditions` | []Object | Tracks state such as readiness for the pool. | +| `status.allocatedCIDR` | string | The CIDR carved for this pool. For child pools this is the sub-prefix allocated from the parent. | +| `status.ipFamily` | string | The effective address family of the pool: taken from `spec.ipFamily` on root pools and derived from `status.allocatedCIDR` on child pools. | +| `status.capacity` | Object | The address-count view of the pool. Counts are exact for IPv4; for address spaces larger than an int64 (wide IPv6 prefixes) `total` saturates to the maximum int64 and `allocated`/`available` are clamped to non-negative values. | +| `status.capacity.total` | integer | Total number of addresses in the pool. | +| `status.capacity.allocated` | integer | Number of addresses currently allocated. | +| `status.capacity.available` | integer | Number of addresses currently available. | +| `status.utilizationPercent` | integer | The allocated share of the pool's address space, 0–100, computed with arbitrary-precision arithmetic so it is accurate for both IPv4 and IPv6. | +| `status.largestFreePrefix` | integer | The prefix length of the largest free aligned block currently available (for example, 45 for a free `/45`). Zero when the pool is exhausted or its capacity is not yet computed. This is the family-agnostic signal for remaining headroom. | + +## Usage + +```yaml +apiVersion: ipam.miloapis.com/v1alpha1 +kind: IPPool +metadata: + name: primary-ipv4 +spec: + cidr: 10.0.0.0/16 + ipFamily: IPv4 +``` + +```bash +datumctl apply -f ippool.yaml +datumctl get ippools +datumctl describe ippool primary-ipv4 +``` + + + Run `datumctl explain ippools --recursive` to see the full, live field tree for this resource. + diff --git a/api/ipam/overview.mdx b/api/ipam/overview.mdx new file mode 100644 index 0000000..bb29a0a --- /dev/null +++ b/api/ipam/overview.mdx @@ -0,0 +1,38 @@ +--- +title: "IPAM" +sidebarTitle: "Overview" +description: "IP address management on Datum Cloud — claims against allocatable pools and the allocations they produce." +--- + +Datum Cloud manages IP address space through the `ipam.miloapis.com` API. You submit a claim requesting a sub-prefix of a given size and family from an allocatable pool, and the system records the resulting allocation carved out of the pool. Claims and allocations are resources you create and inspect with `datumctl apply -f` and `datumctl get`. + + + The IPAM API is **alpha** (`v1alpha1`). Fields and behavior may change in backward-incompatible ways between releases. + + +## Resources + + + + A request for a sub-prefix of a chosen size and IP family, satisfied from a referenced or selected pool. + + + A record of the CIDR carved out of an IPPool to satisfy an IPClaim. + + + +**Platform-provided:** the [IPPool](/api/ipam/ippool) that a claim allocates from lives under [Platform resources](/api/platform/overview). + +## How the pieces fit together + +- An **IPClaim** requests a sub-prefix by IP family (`spec.ipFamily`) and size (`spec.prefixLength`), targeting an **IPPool** by reference (`spec.poolRef`) or selector (`spec.poolSelector`). +- An **IPAllocation** records the specific CIDR carved out of an **IPPool** to satisfy an **IPClaim**. + + + Inspect the exact fields for any resource with `datumctl explain`, for example `datumctl explain ipclaims.spec` or `datumctl explain ipallocations.spec`. + + +## Learn more + +- [API resources overview](/api/overview) — the resource reference landing page across all Datum Cloud services. +- [Changing resources](/datumctl/resources/changing) — how to apply, edit, and safely preview changes to these resources. diff --git a/api/networking/domain.mdx b/api/networking/domain.mdx new file mode 100644 index 0000000..e558681 --- /dev/null +++ b/api/networking/domain.mdx @@ -0,0 +1,69 @@ +--- +title: "Domain" +sidebarTitle: "Domain" +description: "Domain represents a domain name in the Datum system." +--- + + + API resource reference for **Domain**, part of the [Networking service](/api/networking/overview). To create or change one, see [Changing resources](/datumctl/resources/changing); to read or inspect, see [Reading resources](/datumctl/resources/reading). For the underlying concept, see [Domains & DNS](/domain-dns/dns). + + + + The `networking.datumapis.com/v1alpha` API is **alpha** and subject to change. Fields and behavior may change in future releases. + + +## Identity + +| | | +| --- | --- | +| Group | `networking.datumapis.com` | +| Version | `v1alpha` | +| Kind | `Domain` | +| Scope | Project | + +## Overview + +A `Domain` represents a fully qualified domain name (FQDN) that Datum Cloud manages on your behalf. You create a `Domain` to bring a domain under management so that Datum can track its registration and verification status and discover its authoritative nameservers. Each `Domain` lives in a Project. + +## Spec fields + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `spec.domainName` | string | Yes | The fully qualified domain name (FQDN) to be managed. | +| `spec.desiredRegistrationRefreshAttempt` | string | No | The desired time of the next registration refresh attempt. | + +## Status fields (read-only) + +| Field | Type | Description | +| --- | --- | --- | +| `status.apex` | boolean | True when `spec.domainName` is the registered domain (eTLD+1). | +| `status.conditions` | []Object | Conditions describing the current state of the Domain. | +| `status.nameservers` | []Object | The authoritative NS for the effective domain name. If `apex` is true, taken from RDAP for the registered domain (eTLD+1); if false, taken from DNS delegation for the subdomain, falling back to apex NS if there is no cut. | +| `status.registration` | Object | Registration information for the domain. | +| `status.verification` | Object | Verification status of the domain. | + +## Usage + +```yaml +apiVersion: networking.datumapis.com/v1alpha +kind: Domain +metadata: + name: example-com +spec: + domainName: example.com +``` + +```bash +# Create or update the Domain +datumctl apply -f domain.yaml --project my-project + +# List Domains in the project +datumctl get domains --project my-project + +# Inspect a single Domain +datumctl describe domain example-com --project my-project +``` + + + Run `datumctl explain domains --recursive` to see the full, live field tree for this resource. + diff --git a/api/networking/envoy/backend.mdx b/api/networking/envoy/backend.mdx new file mode 100644 index 0000000..0fbd935 --- /dev/null +++ b/api/networking/envoy/backend.mdx @@ -0,0 +1,81 @@ +--- +title: "Backend" +sidebarTitle: "Backend" +description: "Backend allows the user to configure the endpoints of a backend and the behavior of the connection from Envoy Proxy to the backend." +--- + + + API resource reference for **Backend**, an [Envoy Gateway](/api/networking/envoy/overview) extension resource. To create or change one, see [Changing resources](/datumctl/resources/changing); to inspect, see [Reading resources](/datumctl/resources/reading). + + + + This resource is part of the `v1alpha1` Envoy Gateway extension API and is subject to change. Fields and behavior may change in future releases. + + +## Identity + +| | | +| --- | --- | +| Group | `gateway.envoyproxy.io` | +| Version | `v1alpha1` | +| Kind | `Backend` | +| Scope | Project | + +## Overview + +A `Backend` defines a set of network endpoints that traffic can be routed to, along with the behavior of the connection from the Datum Cloud gateway data plane to those endpoints. It is an Envoy Gateway extension to the Gateway API, defined by the [Envoy Gateway API](https://gateway.envoyproxy.io/docs/api/extension_types/): instead of routing to a Service, a route can reference a `Backend` to reach fully qualified domain names, raw IP addresses, or Unix domain sockets — with optional TLS origination and fallback behavior. + +Use a `Backend` when you need to send traffic to a destination that is described by an explicit address (for example, an external API reachable by FQDN) rather than a Service in your Project, or when you need per-backend TLS or failover controls. + +## Spec fields + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `spec.type` | string | No | Backend type. One of `Endpoints` (default) or `DynamicResolver`. | +| `spec.endpoints` | []Object | No | The endpoints to connect to. Each entry is exactly one of `fqdn`, `ip`, or `unix`. | +| `spec.endpoints[].fqdn` | Object | No | A fully qualified domain name endpoint. | +| `spec.endpoints[].fqdn.hostname` | string | Yes* | The FQDN hostname of the endpoint (*required when `fqdn` is set). | +| `spec.endpoints[].fqdn.port` | integer | Yes* | The port of the endpoint (*required when `fqdn` is set). | +| `spec.endpoints[].ip` | Object | No | An IP endpoint. Supports IPv4 and IPv6. | +| `spec.endpoints[].ip.address` | string | Yes* | The IP address of the endpoint (*required when `ip` is set). | +| `spec.endpoints[].ip.port` | integer | Yes* | The port of the endpoint (*required when `ip` is set). | +| `spec.endpoints[].unix` | Object | No | A Unix domain socket endpoint. | +| `spec.endpoints[].hostname` | string | No | Optional hostname for the endpoint. | +| `spec.endpoints[].zone` | string | No | The service zone of the endpoint. | +| `spec.appProtocols` | []string | No | Application protocols supported when connecting to the backend. | +| `spec.fallback` | boolean | No | Marks the backend as a fallback. Fallback backends only receive traffic when the health of the active backends drops (they begin serving once active health falls below roughly 72%). Configure active or passive health checks so failover is detected and reversed automatically. | +| `spec.tls` | Object | No | TLS settings for connecting to the backend. When both this and a `BackendTLSPolicy` apply, the settings are merged and the policy's values win on overlap. | +| `spec.tls.caCertificateRefs` | []Object | No | One or more references to objects containing the CA certificates used as trust anchors to validate the backend's certificate (a single reference with the CA in a `ca.crt` key is currently supported). Either this or `wellKnownCACertificates` must be set, but not both. | +| `spec.tls.wellKnownCACertificates` | string | No | Use system-provided CA certificates for the handshake. Only value is `System`. Either this or `caCertificateRefs` must be set, but not both. | +| `spec.tls.insecureSkipVerify` | boolean | No | Skip verification of the backend's certificate. Defaults to `false`. | + +## Status fields (read-only) + +| Field | Type | Description | +| --- | --- | --- | +| `status.conditions` | []Object | Describes the current conditions of the Backend. | + +## Usage + +```yaml +apiVersion: gateway.envoyproxy.io/v1alpha1 +kind: Backend +metadata: + name: example-api +spec: + type: Endpoints + endpoints: + - fqdn: + hostname: api.example.com + port: 443 +``` + +```bash +datumctl apply -f backend.yaml --project my-project +datumctl get backends --project my-project +datumctl describe backend example-api --project my-project +``` + + + Run `datumctl explain backends --recursive` to see the full, live field tree for this resource. + diff --git a/api/networking/envoy/backendtrafficpolicy.mdx b/api/networking/envoy/backendtrafficpolicy.mdx new file mode 100644 index 0000000..a87a7fc --- /dev/null +++ b/api/networking/envoy/backendtrafficpolicy.mdx @@ -0,0 +1,120 @@ +--- +title: "BackendTrafficPolicy" +sidebarTitle: "BackendTrafficPolicy" +description: "BackendTrafficPolicy allows the user to configure the behavior of the connection between the Envoy Proxy listener and the backend service." +--- + + + API resource reference for **BackendTrafficPolicy**, an [Envoy Gateway](/api/networking/envoy/overview) extension resource. To create or change one, see [Changing resources](/datumctl/resources/changing); to inspect, see [Reading resources](/datumctl/resources/reading). + + + + This resource is part of the `v1alpha1` API and is subject to change. Fields and behavior may change in future releases. + + +## Identity + +| | | +| --- | --- | +| Group | `gateway.envoyproxy.io` | +| Version | `v1alpha1` | +| Kind | `BackendTrafficPolicy` | +| Scope | Project | + +## Overview + +A `BackendTrafficPolicy` tunes how the gateway sends traffic from a listener to the backend services behind it. It is an Envoy Gateway extension to the [Gateway API](https://gateway-api.sigs.k8s.io/) standard, defined by the [Envoy Gateway API](https://gateway.envoyproxy.io/docs/api/extension_types/): you attach it to a `Gateway` or route resource and use it to shape connection behavior — load balancing, retries, timeouts, circuit breaking, rate limiting, active health checks, fault injection, and more. + +Use it when you need finer control over backend traffic than the route itself provides, for example to cap concurrent connections to a backend, retry failed upstream requests, apply rate limits, or gradually ramp traffic to newly added endpoints. The policy attaches to a target resource through `targetRefs` and takes effect within the same Project. + +## Spec fields + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `spec.targetRefs` | []Object | No | Target resources (typically Gateways) this policy attaches to. | +| `spec.targetRefs[].group` | string | Yes | Group of the target resource. | +| `spec.targetRefs[].kind` | string | Yes | Kind of the target resource. | +| `spec.targetRefs[].name` | string | Yes | Name of the target resource. | +| `spec.targetRefs[].sectionName` | string | No | A section within the target (Gateway listener name, route rule name, or Service port name). Targets the whole resource when unset. | +| `spec.targetSelectors` | []Object | No | Selects target resources for this policy by label. | +| `spec.targetRef` | Object | No | Single target resource this policy attaches to. Deprecated: use `targetRefs`/`targetSelectors` instead. | +| `spec.mergeType` | string | No | How this configuration merges into a parent policy (one targeting a Gateway or Listener). Cannot be set when targeting a parent resource. | +| `spec.loadBalancer` | Object | No | Load balancer policy for routing to backend endpoints. Defaults to `LeastRequest`. | +| `spec.loadBalancer.type` | string | Yes* | Load balancer type: `ConsistentHash`, `LeastRequest`, `Random`, or `RoundRobin`. Required when `loadBalancer` is set. | +| `spec.loadBalancer.consistentHash` | Object | No | Configuration used when `type` is `ConsistentHash`. | +| `spec.loadBalancer.slowStart` | Object | No | Gradually increases traffic to newly added hosts (RoundRobin/LeastRequest only). | +| `spec.loadBalancer.zoneAware` | Object | No | Distributes requests across locality zones. | +| `spec.retry` | Object | No | Retry behavior. Disabled when unset. | +| `spec.retry.numRetries` | integer | No | Number of retries to attempt. Defaults to `2`. | +| `spec.retry.perRetry` | Object | No | Retry policy applied per retry attempt (e.g. per-try timeout, backoff). | +| `spec.retry.retryOn` | Object | No | Conditions that trigger a retry (e.g. connect failure, retriable status codes). | +| `spec.timeout` | Object | No | Timeout settings for backend connections. | +| `spec.timeout.http` | Object | No | HTTP timeout settings. | +| `spec.timeout.tcp` | Object | No | TCP timeout settings. | +| `spec.circuitBreaker` | Object | No | Circuit breaker thresholds for upstream connections and requests. Enabled with defaults when unset. | +| `spec.circuitBreaker.maxConnections` | integer | No | Maximum connections Envoy establishes to the backend. | +| `spec.circuitBreaker.maxParallelRequests` | integer | No | Maximum parallel requests to the backend. | +| `spec.circuitBreaker.maxPendingRequests` | integer | No | Maximum pending requests queued to the backend. | +| `spec.circuitBreaker.maxParallelRetries` | integer | No | Maximum parallel retries to the backend. | +| `spec.circuitBreaker.maxRequestsPerConnection` | integer | No | Maximum requests over a single connection. Default: unlimited. | +| `spec.healthCheck` | Object | No | Active/passive health checking of backends. | +| `spec.healthCheck.active` | Object | No | Active health check configuration. | +| `spec.healthCheck.passive` | Object | No | Passive (outlier detection) health check configuration. | +| `spec.healthCheck.panicThreshold` | integer | No | Unhealthy-endpoint threshold at which Envoy balances across all endpoints. Defaults to 50%; `0` disables panic mode. | +| `spec.rateLimit` | Object | No | Limits incoming requests based on attributes of the traffic flow. | +| `spec.rateLimit.type` | string | Yes* | Rate limit scope: `Global` or `Local`. Required when `rateLimit` is set. | +| `spec.rateLimit.local` | Object | No | Local rate limit configuration. | +| `spec.rateLimit.global` | Object | No | Global rate limit configuration. | +| `spec.faultInjection` | Object | No | Injects delays and aborts to mimic failure scenarios such as service failures and overloads. | +| `spec.connection` | Object | No | Backend connection settings. | +| `spec.tcpKeepalive` | Object | No | TCP keepalive settings for the upstream connection. Disabled by default. | +| `spec.proxyProtocol` | Object | No | Enables the Proxy Protocol when communicating with the backend. | +| `spec.compression` | []Object | No | Compression configuration for HTTP streams. | +| `spec.http2` | Object | No | HTTP/2 configuration for backend connections. | +| `spec.httpUpgrade` | []Object | No | HTTP protocol upgrade configuration. Defaults to websocket. | +| `spec.dns` | Object | No | DNS resolution settings. | +| `spec.requestBuffer` | Object | No | Buffers and fully receives each request before forwarding upstream, shielding backends from slow clients and enforcing a maximum request size. May impact performance. | +| `spec.responseOverride` | []Object | No | Overrides specific responses with a custom one. First matching configuration wins. | +| `spec.telemetry` | Object | No | Telemetry settings for the policy target, overriding the EnvoyProxy telemetry settings. | +| `spec.useClientProtocol` | boolean | No | Prefer sending backend requests using the same HTTP protocol as the incoming request. Defaults to `false`. | + + + Fields marked Yes* are required only when their parent object is provided. + + +## Status fields (read-only) + +| Field | Type | Description | +| --- | --- | --- | +| `status.ancestors` | []Object | Ancestor resources (usually Gateways) this policy applies to, with the policy's status for each. A maximum of 16 ancestors are represented; an empty list means the policy is not relevant to any ancestor. | + +## Usage + +```yaml +apiVersion: gateway.envoyproxy.io/v1alpha1 +kind: BackendTrafficPolicy +metadata: + name: backend-traffic-example +spec: + targetRefs: + - group: gateway.networking.k8s.io + kind: Gateway + name: my-gateway + loadBalancer: + type: LeastRequest + retry: + numRetries: 3 + timeout: + http: + requestTimeout: 10s +``` + +```bash +datumctl apply -f backendtrafficpolicy.yaml --project my-project +datumctl get backendtrafficpolicies --project my-project +datumctl describe backendtrafficpolicy backend-traffic-example --project my-project +``` + + + Run `datumctl explain backendtrafficpolicies --recursive` to see the full, live field tree for this resource. + diff --git a/api/networking/envoy/httproutefilter.mdx b/api/networking/envoy/httproutefilter.mdx new file mode 100644 index 0000000..427d227 --- /dev/null +++ b/api/networking/envoy/httproutefilter.mdx @@ -0,0 +1,73 @@ +--- +title: "HTTPRouteFilter" +sidebarTitle: "HTTPRouteFilter" +description: "HTTPRouteFilter is a custom Envoy Gateway HTTPRouteFilter which provides extended traffic processing options such as path regex rewrite, direct response and more." +--- + + + API resource reference for **HTTPRouteFilter**, an [Envoy Gateway](/api/networking/envoy/overview) extension resource. To create or change one, see [Changing resources](/datumctl/resources/changing); to inspect, see [Reading resources](/datumctl/resources/reading). + + + + This resource is part of the `v1alpha1` API and is subject to change. Fields and behavior may change in future releases. + + +## Identity + +| | | +| --- | --- | +| Group | `gateway.envoyproxy.io` | +| Version | `v1alpha1` | +| Kind | `HTTPRouteFilter` | +| Scope | Project | + +## Overview + +An `HTTPRouteFilter` is an Envoy Gateway extension to the Gateway API, defined by the [Envoy Gateway API](https://gateway.envoyproxy.io/docs/api/extension_types/), that provides extended HTTP traffic processing options beyond the standard filters. Use it when a route needs behavior such as rewriting URL path or host, returning a fixed direct response, or injecting credentials into requests before they reach a backend. + +You reference an `HTTPRouteFilter` from an `HTTPRoute` (via an extension-reference filter) so the extended processing applies to the matching traffic within a Project. + +## Spec fields + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `spec.credentialInjection` | Object | No | Injects credentials into the request before forwarding to the backend. Useful when the backend requires credentials that the original request does not carry. | +| `spec.credentialInjection.credential` | Object | Yes* | The credential to inject. Required when `credentialInjection` is set. | +| `spec.credentialInjection.header` | string | No | Name of the header the credentials are injected into. Defaults to the `Authorization` header. | +| `spec.credentialInjection.overwrite` | boolean | No | Whether to overwrite the value if the injected header already exists. Defaults to `false`. | +| `spec.directResponse` | Object | No | Returns a fixed response instead of forwarding to a backend. | +| `spec.directResponse.body` | Object | No | Body of the response. | +| `spec.directResponse.contentType` | string | No | Content type of the response, set in the `Content-Type` header. | +| `spec.directResponse.statusCode` | integer | No | HTTP status code of the response. Defaults to `200` if unset. | +| `spec.urlRewrite` | Object | No | Rewrites HTTP URL components such as path and host. | +| `spec.urlRewrite.hostname` | Object | No | Value used to replace the Host header during forwarding. | +| `spec.urlRewrite.path` | Object | No | Defines a path rewrite. | + + + `*` `credentialInjection.credential` is required only when the `credentialInjection` block is present. + + +This resource has no `status` field. + +## Usage + +```yaml +apiVersion: gateway.envoyproxy.io/v1alpha1 +kind: HTTPRouteFilter +metadata: + name: fixed-maintenance-response +spec: + directResponse: + statusCode: 503 + contentType: text/plain +``` + +```bash +datumctl apply -f httproutefilter.yaml --project my-project +datumctl get httproutefilters --project my-project +datumctl describe httproutefilter fixed-maintenance-response --project my-project +``` + + + Run `datumctl explain httproutefilters --recursive` to see the full, live field tree for this resource. + diff --git a/api/networking/envoy/overview.mdx b/api/networking/envoy/overview.mdx new file mode 100644 index 0000000..ac16cfb --- /dev/null +++ b/api/networking/envoy/overview.mdx @@ -0,0 +1,40 @@ +--- +title: "Envoy Gateway" +sidebarTitle: "Overview" +description: "Envoy Gateway extension resources that add implementation-specific traffic and security policy to the Gateway API." +--- + + + These are the [**Envoy Gateway**](https://gateway.envoyproxy.io/) extension resources in Datum Cloud networking. They build on the [Gateway API](/api/networking/gateway/overview) with implementation-specific policy for traffic behavior and security. For the broader picture, see the [Networking overview](/api/networking/overview). + + + + These resources are part of the `v1alpha1` API and are subject to change. Fields and behavior may change in future releases. + + +## Identity + +| | | +| --- | --- | +| Group | `gateway.envoyproxy.io` | +| Version | `v1alpha1` | + +## Overview + +The Envoy Gateway extension resources extend the [Gateway API](/api/networking/gateway/overview) with implementation-specific traffic and security policy. Where the Gateway API defines the portable core of service traffic routing, these resources let you tune how requests are handled and secured on Datum Cloud's Envoy-based data plane. + +Most of these resources attach to existing Gateway API objects (such as Gateways and HTTPRoutes) through **target references** — you point the policy at the object it should apply to rather than embedding the configuration inline. + +## Resources + +| Resource | Purpose | +| --- | --- | +| [Backend](/api/networking/envoy/backend) | Defines a routing target that traffic can be sent to. | +| [BackendTrafficPolicy](/api/networking/envoy/backendtrafficpolicy) | Tunes traffic behavior for a target, such as timeouts and retries. | +| [SecurityPolicy](/api/networking/envoy/securitypolicy) | Applies authentication and security controls to routes. | +| [HTTPRouteFilter](/api/networking/envoy/httproutefilter) | Adds custom HTTP filters to route processing. | + +## Related + +- [Gateway API overview](/api/networking/gateway/overview) — the portable core routing resources these extensions build on. +- [Networking overview](/api/networking/overview) — all Datum Cloud networking resources. diff --git a/api/networking/envoy/securitypolicy.mdx b/api/networking/envoy/securitypolicy.mdx new file mode 100644 index 0000000..2c18c9c --- /dev/null +++ b/api/networking/envoy/securitypolicy.mdx @@ -0,0 +1,89 @@ +--- +title: "SecurityPolicy" +sidebarTitle: "SecurityPolicy" +description: "SecurityPolicy allows the user to configure various security settings for a Gateway." +--- + + + API resource reference for **SecurityPolicy**, an [Envoy Gateway](/api/networking/envoy/overview) extension resource. To create or change one, see [Changing resources](/datumctl/resources/changing); to inspect, see [Reading resources](/datumctl/resources/reading). + + + + This resource is part of the `v1alpha1` API (an Envoy Gateway extension) and is subject to change. Fields and behavior may change in future releases. + + +## Identity + +| | | +| --- | --- | +| Group | `gateway.envoyproxy.io` | +| Version | `v1alpha1` | +| Kind | `SecurityPolicy` | +| Scope | Project | + +## Overview + +A `SecurityPolicy` applies security controls to a Gateway or to a route served by it. It is an Envoy Gateway extension to the Gateway API standard, defined by the [Envoy Gateway API](https://gateway.envoyproxy.io/docs/api/extension_types/), attached to a target resource through a policy reference rather than being embedded in the Gateway itself. + +Use it when you want to enforce authentication, authorization, or browser access rules on traffic entering your Project — for example requiring JWT or OIDC login, checking API keys or HTTP Basic credentials, delegating to an external authorization service, or configuring Cross-Origin Resource Sharing (CORS). A single policy attaches to one or more Gateways (or specific listeners/routes) and must live in the same Project as the resources it targets. + +## Spec fields + +Each of the security features below is optional; set the ones you want to enforce. `targetRefs` selects what the policy applies to. + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `spec.targetRefs` | []Object | No | The Gateway resources this policy attaches to. Attach by direct reference. | +| `spec.targetRefs[].group` | string | Yes | Group of the target resource. | +| `spec.targetRefs[].kind` | string | Yes | Kind of the target resource. | +| `spec.targetRefs[].name` | string | Yes | Name of the target resource. | +| `spec.targetRefs[].sectionName` | string | No | A section within the target: a Gateway listener name, an HTTPRoute rule name, or a Service port name. When unset, targets the whole resource. | +| `spec.targetSelectors` | []Object | No | Attach to resources by label instead of by name (`kind` required; `group`, `matchLabels`, `matchExpressions` optional). | +| `spec.targetRef` | Object | No | Deprecated single-target reference. Use `targetRefs`/`targetSelectors` instead. | +| `spec.jwt` | Object | No | JSON Web Token authentication. Requires `providers`; set `optional` to allow missing (but not invalid) tokens. | +| `spec.oidc` | Object | No | OpenID Connect authentication. Requires a client secret; supply `clientID` (or `clientIDRef`) and optional cookie settings. | +| `spec.apiKeyAuth` | Object | No | API key authentication. | +| `spec.basicAuth` | Object | No | HTTP Basic authentication. | +| `spec.extAuth` | Object | No | Delegate authorization to an external service. | +| `spec.authorization` | Object | No | Ordered allow/deny rules; `defaultAction` (`Allow` or `Deny`) applies when no rule matches (defaults to `Deny`). | +| `spec.cors` | Object | No | Cross-Origin Resource Sharing settings (`allowOrigins`, `allowMethods`, `allowHeaders`, `exposeHeaders`, `allowCredentials`, `maxAge`). | + +## Status fields (read-only) + +| Field | Type | Description | +| --- | --- | --- | +| `status.ancestors` | []Object | The ancestor resources (usually Gateways) this policy is associated with, and the policy's status against each. Up to 16 entries; an empty list means the policy applies to nothing. | + +## Usage + +```yaml +apiVersion: gateway.envoyproxy.io/v1alpha1 +kind: SecurityPolicy +metadata: + name: require-cors +spec: + targetRefs: + - group: gateway.networking.k8s.io + kind: Gateway + name: my-gateway + cors: + allowOrigins: + - "https://app.example.com" + allowMethods: + - GET + - POST + allowHeaders: + - "*" + allowCredentials: true + maxAge: 1h +``` + +```bash +datumctl apply -f securitypolicy.yaml --project my-project +datumctl get securitypolicies --project my-project +datumctl describe securitypolicy require-cors --project my-project +``` + + + Run `datumctl explain securitypolicies --recursive` to see the full, live field tree for this resource. + diff --git a/api/networking/gateway/backendtlspolicy.mdx b/api/networking/gateway/backendtlspolicy.mdx new file mode 100644 index 0000000..2f45fbb --- /dev/null +++ b/api/networking/gateway/backendtlspolicy.mdx @@ -0,0 +1,80 @@ +--- +title: "BackendTLSPolicy" +sidebarTitle: "BackendTLSPolicy" +description: "BackendTLSPolicy provides a way to configure how a Gateway connects to a Backend via TLS." +--- + + + API resource reference for **BackendTLSPolicy**, one of the [Gateway API](/api/networking/gateway/overview) resources. To create or change one, see [Changing resources](/datumctl/resources/changing); to inspect, see [Reading resources](/datumctl/resources/reading). + + + + This resource follows the [Gateway API BackendTLSPolicy specification](https://gateway-api.sigs.k8s.io/reference/api-types/policy/backendtlspolicy/) and is served at the stable `v1` version. + + +## Identity + +| | | +| --- | --- | +| Group | `gateway.networking.k8s.io` | +| Version | `v1` | +| Kind | `BackendTLSPolicy` | +| Scope | Project | + +## Overview + +A `BackendTLSPolicy` configures how a Gateway establishes a TLS connection to the backend it routes traffic to. It lets you secure the "last mile" between the Gateway and a backend Service by specifying which CA certificates to trust and which hostname the backend's certificate must match. + +Use it when you want traffic between the Gateway and your backend to be encrypted and authenticated — for example, connecting to a backend that serves its own TLS certificate. Each policy attaches to one or more target resources (typically a Service) through `spec.targetRefs`. + +## Spec fields + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `spec.targetRefs` | []Object | Yes | Identifies the resources this policy applies to. Target references must be distinct by the combined `group`, `kind`, and `name` (or by `sectionName` within the same target). Services have Extended support; other kinds are implementation-specific. | +| `spec.targetRefs[].group` | string | Yes | Group of the target resource. | +| `spec.targetRefs[].kind` | string | Yes | Kind of the target resource. | +| `spec.targetRefs[].name` | string | Yes | Name of the target resource. | +| `spec.targetRefs[].sectionName` | string | No | Name of a section within the target (a Service port, a Gateway listener, or an HTTPRoute rule). When unset, the policy targets the entire resource. | +| `spec.validation` | Object | Yes | Backend TLS validation configuration (see fields below). | +| `spec.validation.hostname` | string | Yes | Hostname used as the SNI to connect to the backend and, unless `subjectAltNames` is set, to authenticate the certificate the backend serves. | +| `spec.validation.caCertificateRefs` | []Object | No | One or more references to objects holding a PEM-encoded CA certificate bundle used to validate the TLS handshake with the backend. Exactly one of `caCertificateRefs` or `wellKnownCACertificates` must be set. | +| `spec.validation.subjectAltNames` | []Object | No | One or more Subject Alternative Names; when set, the backend certificate must match at least one of them. | +| `spec.validation.wellKnownCACertificates` | string | No | Set to `System` to allow system CA certificates in the handshake. Mutually exclusive with `caCertificateRefs`. | +| `spec.options` | map[string]string | No | Key/value pairs enabling implementation-specific extended TLS configuration, such as a minimum TLS version or cipher suites. Implementation-specific keys must be domain-prefixed (e.g. `example.com/my-custom-option`). | + +## Status fields (read-only) + +| Field | Type | Description | +| --- | --- | --- | +| `status.ancestors` | []Object | The ancestor resources (usually Gateways) associated with this policy, and the policy's status with respect to each. A maximum of 16 ancestors is tracked; an empty list means the policy is not relevant to any ancestor. | +| `status.ancestors[].ancestorRef` | Object | The parent reference this status entry describes. | +| `status.ancestors[].conditions` | []Object | Tracks state such as `Accepted` and `ResolvedRefs` for the policy relative to the ancestor. | +| `status.ancestors[].controllerName` | string | The controller that wrote this status entry, in `domain/path` form. | + +## Usage + +```yaml +apiVersion: gateway.networking.k8s.io/v1 +kind: BackendTLSPolicy +metadata: + name: secure-backend +spec: + targetRefs: + - group: "" + kind: Service + name: my-backend + validation: + hostname: backend.example.com + wellKnownCACertificates: System +``` + +```bash +datumctl apply -f backendtlspolicy.yaml --project my-project +datumctl get backendtlspolicies --project my-project +datumctl describe backendtlspolicy secure-backend --project my-project +``` + + + Run `datumctl explain backendtlspolicies --recursive` to see the full, live field tree for this resource. + diff --git a/api/networking/gateway/gateway.mdx b/api/networking/gateway/gateway.mdx new file mode 100644 index 0000000..ee9476f --- /dev/null +++ b/api/networking/gateway/gateway.mdx @@ -0,0 +1,83 @@ +--- +title: "Gateway" +sidebarTitle: "Gateway" +description: "Gateway represents an instance of a service-traffic handling infrastructure by binding Listeners to a set of IP addresses." +--- + + + API resource reference for **Gateway**, one of the [Gateway API](/api/networking/gateway/overview) resources. To create or change one, see [Changing resources](/datumctl/resources/changing); to inspect, see [Reading resources](/datumctl/resources/reading). + + + + Gateway follows the [Gateway API Gateway specification](https://gateway-api.sigs.k8s.io/reference/api-types/gateway/), an open, portable standard for service traffic routing. + + +## Identity + +| | | +| --- | --- | +| Group | `gateway.networking.k8s.io` | +| Version | `v1` | +| Kind | `Gateway` | +| Scope | Project | + +## Overview + +A `Gateway` is the front door for traffic entering your Datum Cloud Project. It binds one or more **listeners** — logical endpoints defined by a port, protocol, and optional hostname — to a set of IP addresses, and delegates the actual routing of requests to route resources such as `HTTPRoute`. + +You choose the infrastructure that serves the Gateway by referencing a `GatewayClass` through `spec.gatewayClassName`. Each Gateway must declare at least one listener. Use a Gateway when you want to expose services in a Project to inbound traffic (for example, HTTP on port 80 and HTTPS on port 443) and attach routes that decide where matching requests go. + +## Spec fields + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `spec.gatewayClassName` | string | Yes | Name of the `GatewayClass` resource that defines the infrastructure serving this Gateway. | +| `spec.listeners` | []Object | Yes | Logical endpoints bound on the Gateway's addresses. At least one listener must be specified, and each must be distinct by its combination of port, protocol, and (where applicable) hostname. | +| `spec.listeners[].name` | string | Yes | Name of the listener. Must be unique within the Gateway. | +| `spec.listeners[].port` | integer | Yes | Network port the listener accepts traffic on. | +| `spec.listeners[].protocol` | string | Yes | Network protocol the listener expects (for example `HTTP`, `HTTPS`, `TLS`, `TCP`, `UDP`). | +| `spec.listeners[].hostname` | string | No | Virtual hostname to match for protocols that support it. When unspecified, all hostnames match. Wildcard prefixes like `*.example.com` are treated as suffix matches. | +| `spec.listeners[].tls` | Object | No | TLS configuration for the listener. Required when the protocol is `HTTPS` or `TLS`; invalid for `HTTP`, `TCP`, or `UDP`. | +| `spec.listeners[].allowedRoutes` | Object | No | Restricts the types of routes that may attach to this listener and the Projects those routes may live in. | +| `spec.addresses` | []Object | No | Requested address(es) that traffic bound for this Gateway will use. If omitted, addresses may be assigned automatically. | +| `spec.addresses[].type` | string | No | Type of the address being requested. | +| `spec.addresses[].value` | string | No | The requested address value (for example `1.2.3.4` or a hostname). When empty, a matching address is assigned automatically where supported. | +| `spec.infrastructure` | Object | No | Infrastructure-level attributes, including `labels`, `annotations`, and an optional `parametersRef` to a resource holding extra configuration. | + +## Status fields (read-only) + +| Field | Type | Description | +| --- | --- | --- | +| `status.addresses` | []Object | Network addresses that have actually been bound to the Gateway. May differ from `spec.addresses` when addresses are assigned dynamically or a requested address was unusable. | +| `status.conditions` | []Object | Current conditions of the Gateway, such as `Accepted`, `Programmed`, and `Ready`. | +| `status.listeners` | []Object | Per-listener status for each unique listener port defined in the spec. | + +## Usage + +```yaml +apiVersion: gateway.networking.k8s.io/v1 +kind: Gateway +metadata: + name: web-gateway +spec: + gatewayClassName: datum-external-global-proxy + listeners: + - name: http + port: 80 + protocol: HTTP + - name: https + port: 443 + protocol: HTTPS + tls: + mode: Terminate +``` + +```bash +datumctl apply -f gateway.yaml --project my-project +datumctl get gateways --project my-project +datumctl describe gateway web-gateway --project my-project +``` + + + Run `datumctl explain gateways --recursive` to see the full, live field tree for this resource. + diff --git a/api/networking/gateway/gatewayclass.mdx b/api/networking/gateway/gatewayclass.mdx new file mode 100644 index 0000000..a578c62 --- /dev/null +++ b/api/networking/gateway/gatewayclass.mdx @@ -0,0 +1,71 @@ +--- +title: "GatewayClass" +sidebarTitle: "GatewayClass" +description: "GatewayClass describes a class of Gateways available for creating Gateway resources." +--- + + + **Platform-provided resource.** Datum operates this resource; you typically reference or read it rather than create it. See [Platform resources](/api/platform/overview). + + + + API resource reference for **GatewayClass**. See [Platform resources](/api/platform/overview) for related platform-provided resources. A [Gateway](/api/networking/gateway/gateway) selects the class it is based on. To read or inspect, see [Reading resources](/datumctl/resources/reading). + + + + `GatewayClass` follows the [Gateway API GatewayClass specification](https://gateway-api.sigs.k8s.io/reference/api-types/gatewayclass/), an open, portable standard for service traffic routing. + + +## Identity + +| | | +| --- | --- | +| Group | `gateway.networking.k8s.io` | +| Version | `v1` | +| Kind | `GatewayClass` | +| Scope | Platform | + +## Overview + +A `GatewayClass` defines a class of Gateways that you can use to create `Gateway` resources within Datum Cloud. It names the controller responsible for managing Gateways of the class and can carry default configuration parameters that those Gateways inherit. + +Because it is Platform-scoped, a `GatewayClass` is shared across the platform rather than owned by a single Project. A `Gateway` is typically based on the state of its `GatewayClass` at creation time, so later changes to the class are not necessarily propagated to existing Gateways. This limits the blast radius of changes to a class or its parameters. + +## Spec fields + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `spec.controllerName` | string | Yes | Name of the controller managing Gateways of this class, as a domain-prefixed path (e.g. `example.net/gateway-controller`). Immutable and cannot be empty. | +| `spec.description` | string | No | Free-form text describing the GatewayClass. | +| `spec.parametersRef` | Object | No | Reference to a resource holding configuration parameters for this class. Optional when the controller needs no extra configuration. | +| `spec.parametersRef.group` | string | Yes | Group of the referenced resource. | +| `spec.parametersRef.kind` | string | Yes | Kind of the referenced resource. | +| `spec.parametersRef.name` | string | Yes | Name of the referenced resource. | +| `spec.parametersRef.namespace` | string | No | Project of the referenced resource. Required for a Project-scoped referent; must be unset for a Platform-scoped referent. | + +## Status fields (read-only) + +| Field | Type | Description | +| --- | --- | --- | +| `status.conditions` | []Object | Current status reported by the controller for this GatewayClass, such as whether it has been Accepted. | + +## Usage + +```yaml +apiVersion: gateway.networking.k8s.io/v1 +kind: GatewayClass +metadata: + name: datum-external +spec: + controllerName: gateway.networking.datum.net/gateway-controller +``` + +```bash +datumctl apply -f gatewayclass.yaml --project my-project +datumctl get gatewayclasses --project my-project +datumctl describe gatewayclass datum-external --project my-project +``` + + + Run `datumctl explain gatewayclasses --recursive` to see the full, live field tree for this resource. + diff --git a/api/networking/gateway/httproute.mdx b/api/networking/gateway/httproute.mdx new file mode 100644 index 0000000..667e217 --- /dev/null +++ b/api/networking/gateway/httproute.mdx @@ -0,0 +1,87 @@ +--- +title: "HTTPRoute" +sidebarTitle: "HTTPRoute" +description: "HTTPRoute provides a way to route HTTP requests. This includes the capability to match requests by hostname, path, header, or query param. Filters can be used to specify additional processing steps. Backends specify where matching requests should be routed." +--- + + + API resource reference for **HTTPRoute**, one of the [Gateway API](/api/networking/gateway/overview) resources. To create or change one, see [Changing resources](/datumctl/resources/changing); to inspect, see [Reading resources](/datumctl/resources/reading). + + + + `HTTPRoute` is a stable (`v1`) resource that follows the [Gateway API HTTPRoute specification](https://gateway-api.sigs.k8s.io/reference/api-types/httproute/) for service traffic routing. + + +## Identity + +| | | +| --- | --- | +| Group | `gateway.networking.k8s.io` | +| Version | `v1` | +| Kind | `HTTPRoute` | +| Scope | Project | + +## Overview + +An `HTTPRoute` defines how incoming HTTP requests are routed to backends. It attaches to one or more Gateways (via `parentRefs`) and describes, through a list of `rules`, how to match requests — by hostname, path, header, method, or query parameter — and where to forward the ones that match. Each rule can also apply filters to modify requests along the way. + +Use an `HTTPRoute` to expose an application through a Datum Cloud Gateway: for example, to send `api.example.com/v1` traffic to one backend and everything else to another, or to split traffic across backends by weight. + +## Spec fields + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `spec.hostnames` | []string | No | Hostnames matched against the HTTP `Host` header to select this route. Supports a leading wildcard label (e.g. `*.example.com`). IP addresses are not allowed. | +| `spec.parentRefs` | []Object | No | References to the resources (usually Gateways) this route attaches to. The referenced parent must allow the attachment. | +| `spec.parentRefs[].name` | string | Yes | Name of the referenced parent resource (e.g. the Gateway). | +| `spec.parentRefs[].group` | string | No | API group of the parent resource. Defaults to the Gateway API group. | +| `spec.parentRefs[].kind` | string | No | Kind of the parent resource (e.g. `Gateway`). | +| `spec.parentRefs[].namespace` | string | No | Scope of the parent resource, when it lives outside this route's own scope. | +| `spec.parentRefs[].sectionName` | string | No | Name of a specific section (e.g. a Gateway listener) within the parent to attach to. | +| `spec.parentRefs[].port` | integer | No | Network port of the parent resource this route targets. | +| `spec.rules` | []Object | No | A list of matchers, filters, and actions. Each rule matches requests and forwards them to backends. | +| `spec.rules[].matches` | []Object | No | Conditions that select requests for this rule. A match can specify `path`, `headers`, `queryParams`, and `method`. | +| `spec.rules[].backendRefs` | []Object | No | The backend(s) matching requests are sent to. Each entry sets a `name` (required) plus optional `group`, `kind`, `namespace`, `port`, and `weight`. | +| `spec.rules[].filters` | []Object | No | Processing steps (e.g. header modification, redirects) applied to requests matching this rule. | +| `spec.rules[].timeouts` | Object | No | Timeouts applied to requests matching this rule. | + +## Status fields (read-only) + +| Field | Type | Description | +| --- | --- | --- | +| `status.parents` | []Object | The parent resources (usually Gateways) this route is associated with, and the route's status for each. Up to 32 parents are represented; an empty list means the route is not attached to any Gateway. | +| `status.parents[].parentRef` | Object | Reference to the specific parent this status entry describes. | +| `status.parents[].controllerName` | string | Name of the controller that wrote this status entry. | +| `status.parents[].conditions` | []Object | Conditions such as `Accepted` and `ResolvedRefs` describing attachment readiness for this parent. | + +## Usage + +```yaml +apiVersion: gateway.networking.k8s.io/v1 +kind: HTTPRoute +metadata: + name: example-route +spec: + parentRefs: + - name: example-gateway + hostnames: + - api.example.com + rules: + - matches: + - path: + type: PathPrefix + value: /v1 + backendRefs: + - name: example-backend + port: 8080 +``` + +```bash +datumctl apply -f httproute.yaml --project my-project +datumctl get httproutes --project my-project +datumctl describe httproute example-route --project my-project +``` + + + Run `datumctl explain httproutes --recursive` to see the full, live field tree for this resource. + diff --git a/api/networking/gateway/overview.mdx b/api/networking/gateway/overview.mdx new file mode 100644 index 0000000..4d9892f --- /dev/null +++ b/api/networking/gateway/overview.mdx @@ -0,0 +1,44 @@ +--- +title: "Gateway API" +sidebarTitle: "Overview" +description: "API reference for the Gateway API resources on Datum Cloud — an open, portable standard for routing service traffic with Gateway, HTTPRoute, and BackendTLSPolicy." +--- + +Datum Cloud exposes the [**Gateway API**](https://gateway-api.sigs.k8s.io/) — an open, portable standard for routing service traffic. Rather than a single monolithic object, the Gateway API splits traffic handling into a small set of composable resources, so you can describe the infrastructure, the entry points, and the routing rules independently and let them reference one another. + + + These resources follow the Gateway API standard and are served at the stable `v1` version. + + +## How the resources compose + +The Gateway API resources build on one another, from the underlying infrastructure up to the individual routing rules: + +- [Gateway](/api/networking/gateway/gateway) binds listeners and addresses. It instantiates a GatewayClass, opening one or more listeners (protocol, port, and hostname) at network addresses where traffic arrives. +- [HTTPRoute](/api/networking/gateway/httproute) routes HTTP requests to backends. It attaches to a Gateway and describes how matching requests are filtered and forwarded to backend services. +- [BackendTLSPolicy](/api/networking/gateway/backendtlspolicy) configures TLS to backends. It describes how a Gateway establishes a TLS connection to the backends that an HTTPRoute forwards to. + + + + Bind listeners and addresses where traffic enters the platform. + + + Route HTTP requests to backends with matches, filters, and forwarding rules. + + + Configure the TLS connection a Gateway makes to its backends. + + + +**Platform-provided:** the [GatewayClass](/api/networking/gateway/gatewayclass) referenced by a gateway lives under [Platform resources](/api/platform/overview). + +You create and update these resources declaratively with `datumctl apply -f`, and inspect them with `datumctl get` and `datumctl describe`. + +## Relationship to HTTPProxy + +The Gateway API resources and Datum's higher-level [HTTPProxy](/api/networking/httpproxy) are both ways to expose HTTP services on Datum Cloud. HTTPProxy builds on top of Gateway API resources to cover simple reverse-proxy use cases without configuring the underlying gateway resources directly, while the Gateway API resources give you direct control over classes, listeners, routes, and backend TLS. Which fits depends on how much of the routing surface you need to manage yourself. + +## Learn more + +- [Networking overview](/api/networking/overview) — the networking service and the other resources it groups. +- [Changing resources](/datumctl/resources/changing) — how to apply, edit, and safely preview changes with `datumctl`. diff --git a/api/networking/httpproxy.mdx b/api/networking/httpproxy.mdx new file mode 100644 index 0000000..820d6f4 --- /dev/null +++ b/api/networking/httpproxy.mdx @@ -0,0 +1,77 @@ +--- +title: "HTTPProxy" +sidebarTitle: "HTTPProxy" +description: "An HTTPProxy provides a convenient way to manage simple reverse proxy use cases." +--- + + + API resource reference for **HTTPProxy**, part of the [Networking service](/api/networking/overview). To create or change one, see [Changing resources](/datumctl/resources/changing); to read or inspect, see [Reading resources](/datumctl/resources/reading). + + + + HTTPProxy is an **alpha** API (`v1alpha`) and is subject to change. Fields and behavior may change in future releases. + + +## Identity + +| | | +| --- | --- | +| **Group** | `networking.datumapis.com` | +| **Version** | `v1alpha` | +| **Kind** | `HTTPProxy` | +| **Scope** | Project | + +## Overview + +An HTTPProxy builds on top of Gateway API resources to provide a more convenient way to manage simple reverse proxy use cases. You define a set of hostnames to match against the incoming HTTP `Host` header along with routing rules that match, filter, and forward requests to backends. Use it when you want to expose one or more backends behind a stable, platform-managed hostname without configuring the underlying gateway resources directly. + +## Spec fields + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `spec.hostnames` | []string | No | Hostnames that should match against the HTTP `Host` header to select this HTTPProxy. Values follow RFC 1123 (IPs and wildcards are not allowed). Hostnames must be verified via `Domain` resources and must be unique across the platform; unverified or conflicting hostnames are reported on the `HostnamesVerified` condition. | +| `spec.rules` | []Object | Yes | A list of HTTP matchers, filters, and actions. Each rule matches an HTTP request based on conditions, processes it, and forwards it to backends. | +| `spec.rules[].name` | string | No | Name of the route rule. Must be unique within the HTTPProxy if set. | +| `spec.rules[].matches` | []Object | No | Conditions used for matching the rule against incoming HTTP requests. Each match is independent — the rule matches if **any** one of the matches is satisfied. | +| `spec.rules[].filters` | []Object | No | Filters applied to requests that match this rule. | +| `spec.rules[].backends` | []Object | No | Backend(s) where matching requests should be sent. Only a single element is permitted at this time. | +| `spec.rules[].backends[].endpoint` | string | Yes | Endpoint for the backend. Must be a valid URL. Supports `http` and `https`, IP or DNS hosts, custom ports, and paths. | +| `spec.rules[].backends[].connector` | Object | No | References the Connector that should be used for this backend. Only a name reference is supported for now. | +| `spec.rules[].backends[].filters` | []Object | No | Filters executed if and only if the request is forwarded to this backend. | +| `spec.rules[].backends[].tls` | Object | No | Backend TLS configuration. When the backend endpoint uses HTTPS with an IP address, the hostname must be specified for TLS certificate validation. | + +## Status fields (read-only) + +| Field | Type | Description | +| --- | --- | --- | +| `status.addresses` | []Object | Network addresses that have been bound to the HTTPProxy. Does not contain custom hostnames — see the `hostnames` field. | +| `status.canonicalHostname` | string | Platform-managed stable hostname assigned to this HTTPProxy (e.g. `.datumproxy.net`). Create external CNAME or ALIAS records pointing at this hostname to route traffic through the platform. | +| `status.conditions` | []Object | Current conditions of the HTTPProxy. | +| `status.hostnameStatuses` | []Object | Per-hostname status for each configured hostname, including verification and DNS record programming conditions. Use this instead of the deprecated `hostnames` field for detailed per-hostname lifecycle information. | +| `status.hostnames` | []string | Hostnames that have been bound to the HTTPProxy. Deprecated: use `hostnameStatuses` for detailed per-hostname status; this field will be removed in a future API version. | + +## Usage + +```yaml +apiVersion: networking.datumapis.com/v1alpha +kind: HTTPProxy +metadata: + name: example-proxy +spec: + hostnames: + - app.example.com + rules: + - name: default + backends: + - endpoint: https://backend.example.com +``` + +```bash +datumctl apply -f httpproxy.yaml --project my-project +datumctl get httpproxies --project my-project +datumctl describe httpproxy example-proxy --project my-project +``` + + + Run `datumctl explain httpproxies --recursive` for the full, live field tree. + diff --git a/api/networking/network.mdx b/api/networking/network.mdx new file mode 100644 index 0000000..4981bd7 --- /dev/null +++ b/api/networking/network.mdx @@ -0,0 +1,70 @@ +--- +title: "Network" +sidebarTitle: "Network" +description: "Network is the Schema for the networks API." +--- + + + API resource reference for **Network**, part of the [Networking service](/api/networking/overview). To create or change one, see [Changing resources](/datumctl/resources/changing); to read or inspect, see [Reading resources](/datumctl/resources/reading). + + + + The `networking.datumapis.com/v1alpha` API is **alpha** and subject to change. Fields and behavior may change in future releases. + + +## Identity + +| | | +| --- | --- | +| **Group** | `networking.datumapis.com` | +| **Version** | `v1alpha` | +| **Kind** | `Network` | +| **Scope** | Project | + +## Overview + +A Network defines a connectivity fabric within a Datum Cloud project. You use it to establish the IP addressing plan for your workloads — choosing which IP families are permitted, how addresses are allocated (IPAM), and the network MTU. Create a Network when you need a dedicated addressable space for the resources in a project. + +## Spec fields + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `spec.ipFamilies` | `[]string` | No | IP families to permit on a network. Defaults to IPv4. | +| `spec.ipam` | `Object` | Yes | IPAM settings for the network. | +| `spec.ipam.ipv4Range` | `string` | No | IPv4 range to use in auto mode networks. Defaults to `10.128.0.0/9`. | +| `spec.ipam.ipv6Range` | `string` | No | IPv6 range to use in auto mode networks. Defaults to a `/48` allocated from `fd20::/20`. | +| `spec.ipam.mode` | `string` | Yes | IPAM mode. One of `Auto`, `Policy`. | +| `spec.mtu` | `integer` | No | Network MTU. May be between 1300 and 8856. | + +## Status fields (read-only) + +| Field | Type | Description | +| --- | --- | --- | +| `status.conditions` | `[]Object` | Represents the observations of a network's current state. | + +## Usage + +```yaml +apiVersion: networking.datumapis.com/v1alpha +kind: Network +metadata: + name: my-network +spec: + ipam: + mode: Auto +``` + +```bash +# Apply the manifest +datumctl apply -f network.yaml --project my-project + +# List networks in the project +datumctl get networks --project my-project + +# Inspect a single network +datumctl describe network my-network --project my-project +``` + + + Run `datumctl explain networks --recursive` to see the full, live field tree for this resource. + diff --git a/api/networking/overview.mdx b/api/networking/overview.mdx new file mode 100644 index 0000000..6e9d450 --- /dev/null +++ b/api/networking/overview.mdx @@ -0,0 +1,45 @@ +--- +title: "Networking" +sidebarTitle: "Overview" +description: "API reference for the networking.datumapis.com service — networks, subnets, HTTP proxies, and domains on Datum Cloud." +--- + +Datum Cloud networking lets you define and connect the infrastructure your applications run on. The `networking.datumapis.com` service groups the resources that describe your network topology and how traffic reaches your services: private [Networks](/api/networking/network) with their addressing, the [Subnets](/api/networking/subnet) carved out of them, [HTTPProxies](/api/networking/httpproxy) that expose services over HTTP, and the [Domains](/api/networking/domain) that name them. For fine-grained control over how service traffic is routed and secured, Datum Cloud also exposes the standard [Gateway API](/api/networking/gateway/overview) resources and the [Envoy Gateway](/api/networking/envoy/overview) extensions that build on them. You create and update these resources declaratively with `datumctl apply -f`, and inspect them with `datumctl get` and `datumctl describe`. + + + These resources are **alpha** (`v1alpha`). The API surface — fields, defaults, and behavior — may change in backward-incompatible ways between releases. + + +## Piloted resources + +This reference documents a pilot subset of the networking service. More resources exist in `networking.datumapis.com`; the pages below cover the ones available in the pilot. + + + + Define a private network with its IP families, address management, and MTU. + + + Carve an addressable range out of a network. + + + Expose a service over HTTP with a convenient reverse-proxy configuration. + + + Register a domain name in Datum for use by other networking resources. + + + Route service traffic with the open Gateway API standard — classes, gateways, routes, and backend TLS. + + + Extend the Gateway API with implementation-specific traffic and security policy. + + + + + New to editing Datum resources? See [Changing resources](/datumctl/resources/changing) for how to apply, edit, and safely preview changes with `datumctl`. + + +## Learn more + +- [API resources overview](/api/overview) — the resource reference landing page across all Datum Cloud services. +- [Reading resources](/datumctl/resources/reading) — how to list, get, and inspect these resources with `datumctl`. diff --git a/api/networking/subnet.mdx b/api/networking/subnet.mdx new file mode 100644 index 0000000..e509a26 --- /dev/null +++ b/api/networking/subnet.mdx @@ -0,0 +1,82 @@ +--- +title: "Subnet" +sidebarTitle: "Subnet" +description: "Subnet is the Schema for the subnets API." +--- + + + API resource reference for **Subnet**, part of the [Networking service](/api/networking/overview). To create or change one, see [Changing resources](/datumctl/resources/changing); to read or inspect, see [Reading resources](/datumctl/resources/reading). + + + + This resource is part of an **alpha** API (`v1alpha`). Its fields and behavior are subject to change. + + +## Identity + +| | | +| --- | --- | +| **Group** | `networking.datumapis.com` | +| **Version** | `v1alpha` | +| **Kind** | `Subnet` | +| **Scope** | Project | + +## Overview + +A `Subnet` defines a range of IP addresses within a network context at a specific location. You create one to allocate addressing for a network, specifying the IP family, subnet class, start address, and prefix length. Once created, Datum Cloud tracks the subnet's allocated address range in its status. + +## Spec fields + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `spec.ipFamily` | string | Yes | The IP family of a subnet. One of `IPv4`, `IPv6`. | +| `spec.location` | Object | Yes | The location which a subnet is associated with. | +| `spec.location.name` | string | Yes | Name of a datum location. | +| `spec.location.namespace` | string | Yes | Namespace for the datum location. | +| `spec.networkContext` | Object | Yes | A subnet's network context. | +| `spec.networkContext.name` | string | Yes | The network context name. | +| `spec.prefixLength` | integer | Yes | The prefix length of a subnet. | +| `spec.startAddress` | string | Yes | The start address of a subnet. | +| `spec.subnetClass` | string | Yes | The class of subnet. | + +## Status fields (read-only) + +| Field | Type | Description | +| --- | --- | --- | +| `status.conditions` | []Object | Represents the observations of a subnet's current state. | +| `status.prefixLength` | integer | The prefix length of a subnet. | +| `status.startAddress` | string | The start address of a subnet. | + +## Usage + +```yaml +apiVersion: networking.datumapis.com/v1alpha +kind: Subnet +metadata: + name: my-subnet +spec: + ipFamily: IPv4 + subnetClass: private + startAddress: "10.0.0.0" + prefixLength: 24 + location: + name: my-location + namespace: my-project + networkContext: + name: my-network-context +``` + +```bash +# Create or update the subnet +datumctl apply -f subnet.yaml --project my-project + +# List subnets in the project +datumctl get subnets --project my-project + +# Inspect a single subnet +datumctl describe subnet my-subnet --project my-project +``` + + + Run `datumctl explain subnets --recursive` to see the full, live field tree for this resource. + diff --git a/api/notification/contact.mdx b/api/notification/contact.mdx new file mode 100644 index 0000000..fe0d1d2 --- /dev/null +++ b/api/notification/contact.mdx @@ -0,0 +1,74 @@ +--- +title: "Contact" +sidebarTitle: "Contact" +description: "Contact is the Schema for the contacts API. It represents a contact for a user." +--- + + + API resource reference for **Contact**, part of the [Notification service](/api/notification/overview). To create or change one, see [Changing resources](/datumctl/resources/changing); to inspect, see [Reading resources](/datumctl/resources/reading). + + + + This resource is part of the `v1alpha1` API and is subject to change. Fields and behavior may change in future releases. + + +## Identity + +| | | +| --- | --- | +| Group | `notification.miloapis.com` | +| Version | `v1alpha1` | +| Kind | `Contact` | +| Scope | Project | + +## Overview + +A `Contact` represents a person who can receive notifications from Datum Cloud, tied to a user subject. Use it to register the name and email address that Datum Cloud (and its downstream notification providers) should use when reaching out to a user within a Project. + +## Spec fields + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `spec.email` | string | Yes | The email address for the contact. | +| `spec.givenName` | string | No | The contact's given (first) name. | +| `spec.familyName` | string | No | The contact's family (last) name. | +| `spec.subject` | Object | No | Reference to the subject the contact belongs to. | +| `spec.subject.apiGroup` | string | Yes | API group of the referenced subject. Must be `iam.miloapis.com`. | +| `spec.subject.kind` | string | Yes | Type of subject being referenced. Must be `User`. | +| `spec.subject.name` | string | Yes | Name of the referenced subject. | +| `spec.subject.namespace` | string | No | Namespace of the referenced subject. Required for Project-scoped subjects; omitted for Platform-scoped subjects. | + +## Status fields (read-only) + +| Field | Type | Description | +| --- | --- | --- | +| `status.conditions` | []Object | Latest observations of the contact's state. The standard `Ready` condition tracks contact creation and sync to the contact provider. | +| `status.providers` | []Object | Per-provider status for this contact, enabling multiple provider backends to be tracked simultaneously. | +| `status.providerID` | string | Identifier returned by the underlying contact provider (e.g. Resend) when the contact is created. Deprecated: use `status.providers` instead. | + +## Usage + +```yaml +apiVersion: notification.miloapis.com/v1alpha1 +kind: Contact +metadata: + name: jane-doe +spec: + email: jane.doe@example.com + givenName: Jane + familyName: Doe + subject: + apiGroup: iam.miloapis.com + kind: User + name: jane-doe +``` + +```bash +datumctl apply -f contact.yaml --project my-project +datumctl get contacts --project my-project +datumctl describe contact jane-doe --project my-project +``` + + + Run `datumctl explain contacts --recursive` to see the full, live field tree for this resource. + diff --git a/api/notification/contactgroup.mdx b/api/notification/contactgroup.mdx new file mode 100644 index 0000000..e8e31fb --- /dev/null +++ b/api/notification/contactgroup.mdx @@ -0,0 +1,70 @@ +--- +title: "ContactGroup" +sidebarTitle: "ContactGroup" +description: "ContactGroup is the Schema for the contactgroups API. It represents a logical grouping of Contacts." +--- + + + API resource reference for **ContactGroup**, part of the [Notification service](/api/notification/overview). To create or change one, see [Changing resources](/datumctl/resources/changing); to inspect, see [Reading resources](/datumctl/resources/reading). + + + + This resource is part of the `v1alpha1` API and is subject to change. Fields and behavior may change in future releases. + + +## Identity + +| | | +| --- | --- | +| Group | `notification.miloapis.com` | +| Version | `v1alpha1` | +| Kind | `ContactGroup` | +| Scope | Project | + +## Overview + +A `ContactGroup` represents a logical grouping of Contacts within a Project. Use it to organize the people who should receive notifications, and to control how members join or leave the group. A group can optionally be synced to an external email provider (such as Loops) so the same audience is available there. + +Visibility governs opt-out behavior: a `public` group lets members leave on their own (via a `ContactGroupMembershipRemoval`), while a `private` group enforces membership and rejects opt-out requests. + +## Spec fields + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `spec.displayName` | string | Yes | The display name of the contact group. | +| `spec.visibility` | string | Yes | Whether members may opt in or out. One of `public` (members may leave via `ContactGroupMembershipRemoval`) or `private` (membership is enforced; opt-out requests are rejected). | +| `spec.description` | string | No | Description of the contact group. Email providers (e.g. Loops) also use this on their generated opt-in/opt-out page. Synchronization of this field is not supported. | +| `spec.providers` | []Object | No | The external providers this group should be synced to. | +| `spec.providers[].name` | string | Yes | The provider handling this contact group. Allowed value: `Loops`. | +| `spec.providers[].id` | string | Yes | The identifier of the contact group in the external provider. Used when a provider does not expose an API for creating mailing lists and requires an existing list ID (e.g. Loops); if omitted, a new group is created when the provider supports it. | + +## Status fields (read-only) + +| Field | Type | Description | +| --- | --- | --- | +| `status.conditions` | []Object | Latest observations of the group's state. The standard `Ready` condition tracks group creation and sync to the provider. | +| `status.providers` | []Object | Per-provider status, enabling tracking of multiple provider backends simultaneously. Each entry has `name` (`Resend` or `Loops`) and `id` (the identifier returned by that provider). | +| `status.providerID` | string | Identifier returned by the underlying provider when the group is created. Deprecated: use `status.providers` instead. | + +## Usage + +```yaml +apiVersion: notification.miloapis.com/v1alpha1 +kind: ContactGroup +metadata: + name: platform-alerts +spec: + displayName: Platform Alerts + visibility: public + description: Recipients for platform status and incident notifications. +``` + +```bash +datumctl apply -f contactgroup.yaml --project my-project +datumctl get contactgroups --project my-project +datumctl describe contactgroup platform-alerts --project my-project +``` + + + Run `datumctl explain contactgroups --recursive` to see the full, live field tree for this resource. + diff --git a/api/notification/contactgroupmembership.mdx b/api/notification/contactgroupmembership.mdx new file mode 100644 index 0000000..5a2c2f5 --- /dev/null +++ b/api/notification/contactgroupmembership.mdx @@ -0,0 +1,72 @@ +--- +title: "ContactGroupMembership" +sidebarTitle: "ContactGroupMembership" +description: "ContactGroupMembership is the Schema for the contactgroupmemberships API. It represents a membership of a Contact in a ContactGroup." +--- + + + API resource reference for **ContactGroupMembership**, part of the [Notification service](/api/notification/overview). To create or change one, see [Changing resources](/datumctl/resources/changing); to inspect, see [Reading resources](/datumctl/resources/reading). + + + + This resource is part of the `v1alpha1` API and is subject to change. Fields and behavior may change in future releases. + + +## Identity + +| | | +| --- | --- | +| Group | `notification.miloapis.com` | +| Version | `v1alpha1` | +| Kind | `ContactGroupMembership` | +| Scope | Project | + +## Overview + +A `ContactGroupMembership` links a `Contact` to a `ContactGroup`, adding that contact as a member of the group. Use it when you want a contact to receive notifications sent to a group: create one membership per contact-to-group pairing. The membership references both the target `ContactGroup` and the `Contact` being added, and the controller tracks the sync of that membership to the underlying notification provider. + +## Spec fields + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `spec.contactGroupRef` | Object | Yes | Reference to the ContactGroup that the Contact is a member of. | +| `spec.contactGroupRef.name` | string | Yes | Name of the ContactGroup being referenced. | +| `spec.contactGroupRef.namespace` | string | Yes | Namespace of the ContactGroup being referenced. | +| `spec.contactRef` | Object | Yes | Reference to the Contact that is a member of the ContactGroup. | +| `spec.contactRef.name` | string | Yes | Name of the Contact being referenced. | +| `spec.contactRef.namespace` | string | Yes | Namespace of the Contact being referenced. | + +## Status fields (read-only) + +| Field | Type | Description | +| --- | --- | --- | +| `status.conditions` | []Object | Latest observations of the membership's state. The standard `Ready` condition tracks membership creation and sync to the contact group membership provider. | +| `status.providers` | []Object | Per-provider status for this membership, enabling multiple provider backends to be tracked simultaneously. | +| `status.providerID` | string | Identifier returned by the underlying contact provider (e.g. Resend) when the membership is created in the associated audience. Deprecated: use `status.providers` instead. | +| `status.username` | string | Username of the user that owns the membership, populated by the controller from the referenced Contact's subject. | + +## Usage + +```yaml +apiVersion: notification.miloapis.com/v1alpha1 +kind: ContactGroupMembership +metadata: + name: alice-oncall +spec: + contactGroupRef: + name: oncall + namespace: my-project + contactRef: + name: alice + namespace: my-project +``` + +```bash +datumctl apply -f contactgroupmembership.yaml --project my-project +datumctl get contactgroupmemberships --project my-project +datumctl describe contactgroupmemberships alice-oncall --project my-project +``` + + + Run `datumctl explain contactgroupmemberships --recursive` to see the full, live field tree for this resource. + diff --git a/api/notification/email.mdx b/api/notification/email.mdx new file mode 100644 index 0000000..a5fdbac --- /dev/null +++ b/api/notification/email.mdx @@ -0,0 +1,80 @@ +--- +title: "Email" +sidebarTitle: "Email" +description: "Email is the Schema for the emails API." +--- + + + API resource reference for **Email**, part of the [Notification service](/api/notification/overview). To create or change one, see [Changing resources](/datumctl/resources/changing); to inspect, see [Reading resources](/datumctl/resources/reading). + + + + This resource is part of the `v1alpha1` API and is subject to change. Fields and behavior may change in future releases. + + +## Identity + +| | | +| --- | --- | +| Group | `notification.miloapis.com` | +| Version | `v1alpha1` | +| Kind | `Email` | +| Scope | Project | + +## Overview + +An `Email` represents a concrete message that Datum Cloud should send to a recipient. It references an `EmailTemplate` to render, names the recipient (either a `User` resource or a literal address), and supplies the variables needed to fill in the template. Use it to trigger a one-off notification e-mail within a Project; the platform renders the template, resolves the recipient, and delivers the message, recording the outcome in the resource status. + +## Spec fields + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `spec.templateRef` | Object | Yes | References the `EmailTemplate` that should be rendered. | +| `spec.templateRef.name` | string | Yes | Name of the referenced `EmailTemplate`. | +| `spec.recipient` | Object | Yes | The recipient of the e-mail. Provide exactly one of `userRef` or `emailAddress`. | +| `spec.recipient.userRef` | Object | No | References the `User` resource that will receive the message. Mutually exclusive with `emailAddress`. | +| `spec.recipient.userRef.name` | string | No | Name of the `User` resource that will receive the e-mail. Required when `userRef` is set. | +| `spec.recipient.emailAddress` | string | No | Literal e-mail address for the recipient instead of a `User` reference. Mutually exclusive with `userRef`. | +| `spec.variables` | []Object | No | Name/value pairs substituted into the template. Each entry requires `name` (as declared in the template) and `value`. | +| `spec.priority` | string | No | Influences the order in which pending e-mails are processed. One of `low`, `normal`, `high`. | +| `spec.cc` | []string | No | Additional addresses that receive a carbon copy. Maximum 10 addresses. | +| `spec.bcc` | []string | No | Addresses that receive a blind-carbon copy. Maximum 10 addresses. | + +## Status fields (read-only) + +| Field | Type | Description | +| --- | --- | --- | +| `status.conditions` | []Object | Latest observations of the e-mail's state; the standard `Delivered` condition tracks delivery. | +| `status.emailAddress` | string | The final recipient address used for delivery, after resolving any referenced `User`. | +| `status.subject` | string | The subject line used for the e-mail. | +| `status.htmlBody` | string | The rendered HTML content of the e-mail. | +| `status.textBody` | string | The rendered plain-text content of the e-mail. | +| `status.providerID` | string | Identifier returned by the underlying e-mail provider when the message is accepted for delivery, used to track delivery status. | + +## Usage + +```yaml +apiVersion: notification.miloapis.com/v1alpha1 +kind: Email +metadata: + name: welcome-message +spec: + templateRef: + name: welcome-template + recipient: + emailAddress: person@example.com + variables: + - name: firstName + value: Alex + priority: normal +``` + +```bash +datumctl apply -f email.yaml --project my-project +datumctl get emails --project my-project +datumctl describe emails welcome-message --project my-project +``` + + + Run `datumctl explain emails --recursive` to see the full, live field tree for this resource. + diff --git a/api/notification/emailbroadcast.mdx b/api/notification/emailbroadcast.mdx new file mode 100644 index 0000000..a9f5986 --- /dev/null +++ b/api/notification/emailbroadcast.mdx @@ -0,0 +1,74 @@ +--- +title: "EmailBroadcast" +sidebarTitle: "EmailBroadcast" +description: "EmailBroadcast is the Schema for the emailbroadcasts API. It represents a broadcast of an email to a set of contacts (ContactGroup)." +--- + + + API resource reference for **EmailBroadcast**, part of the [Notification service](/api/notification/overview). To create or change one, see [Changing resources](/datumctl/resources/changing); to inspect, see [Reading resources](/datumctl/resources/reading). + + + + This resource is part of the `v1alpha1` API and is subject to change. Fields and behavior may change in future releases. + + +## Identity + +| | | +| --- | --- | +| Group | `notification.miloapis.com` | +| Version | `v1alpha1` | +| Kind | `EmailBroadcast` | +| Scope | Project | + +## Overview + +An `EmailBroadcast` sends an email to every contact in a `ContactGroup`, rendering the message from a referenced `EmailTemplate`. Use it to deliver a one-time message — such as an announcement or notice — to a defined audience within a Project. + +A broadcast is immutable once created: if you need to change the message, schedule, or audience, delete the resource and create a new one. You can optionally defer delivery with `scheduledAt`; if omitted, the broadcast is sent as soon as the controller reconciles it. + +## Spec fields + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `spec.contactGroupRef` | Object | Yes | References the ContactGroup that the broadcast is sent to. | +| `spec.contactGroupRef.name` | string | Yes | Name of the referenced ContactGroup. | +| `spec.contactGroupRef.namespace` | string | Yes | Namespace of the referenced ContactGroup. | +| `spec.templateRef` | Object | Yes | References the EmailTemplate used to render the message. With the Resend provider, `HTMLBody`/`TextBody` may include `{{{FIRST_NAME}}}`, `{{{LAST_NAME}}}`, and `{{{EMAIL}}}` placeholders that are substituted at send time. | +| `spec.templateRef.name` | string | Yes | Name of the referenced EmailTemplate. | +| `spec.displayName` | string | No | Human-friendly display name for the broadcast. | +| `spec.scheduledAt` | string | No | Time at which the broadcast should be sent (e.g., `2024-08-05T11:52:01.858Z`). If omitted, the message is sent as soon as the resource is reconciled. | + +## Status fields (read-only) + +| Field | Type | Description | +| --- | --- | --- | +| `status.conditions` | []Object | Latest observations of the broadcast's state. The standard `Ready` condition tracks send status and sync to the email provider. | +| `status.providerID` | string | Identifier returned by the underlying email provider (e.g., Resend) when the broadcast is created; used to track send status via provider webhooks. | + +## Usage + +```yaml +apiVersion: notification.miloapis.com/v1alpha1 +kind: EmailBroadcast +metadata: + name: launch-announcement +spec: + displayName: Launch Announcement + contactGroupRef: + name: newsletter-subscribers + namespace: my-project + templateRef: + name: launch-announcement-template + scheduledAt: "2024-08-05T11:52:01.858Z" +``` + +```bash +datumctl apply -f emailbroadcast.yaml --project my-project +datumctl get emailbroadcasts --project my-project +datumctl describe emailbroadcast launch-announcement --project my-project +``` + + + Run `datumctl explain emailbroadcasts --recursive` to see the full, live field tree for this resource. + diff --git a/api/notification/emailtemplate.mdx b/api/notification/emailtemplate.mdx new file mode 100644 index 0000000..61e407e --- /dev/null +++ b/api/notification/emailtemplate.mdx @@ -0,0 +1,78 @@ +--- +title: "EmailTemplate" +sidebarTitle: "EmailTemplate" +description: "EmailTemplate is the Schema for the email templates API. It represents a reusable e-mail template that can be rendered by substituting the declared variables." +--- + + + **Platform-provided resource.** Datum operates this resource; you typically reference or read it rather than create it. See [Platform resources](/api/platform/overview). + + + + API resource reference for **EmailTemplate**. See [Platform resources](/api/platform/overview) for related platform-provided resources. To read or inspect, see [Reading resources](/datumctl/resources/reading). + + + + This resource is part of the `v1alpha1` API and is subject to change. Fields and behavior may change in future releases. + + +## Identity + +| | | +| --- | --- | +| Group | `notification.miloapis.com` | +| Version | `v1alpha1` | +| Kind | `EmailTemplate` | +| Scope | Platform | + +## Overview + +An `EmailTemplate` is a reusable e-mail template that Datum Cloud renders when it needs to send a notification. The template defines a subject line along with HTML and plain-text bodies written as Go template strings, and it enumerates the variables that callers are expected to provide when the message is rendered. Use it to standardize the wording and formatting of notification e-mails so the same content can be produced consistently by substituting the declared variables at send time. + +## Spec fields + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `spec.subject` | string | Yes | The string that composes the email subject line. | +| `spec.htmlBody` | string | Yes | The string for the HTML representation of the message. | +| `spec.textBody` | string | Yes | The Go template string for the plain-text representation of the message. | +| `spec.variables` | []Object | No | Enumerates all variables that can be referenced inside the template expressions. | +| `spec.variables[].name` | string | Yes | The identifier of the variable as it appears inside the Go template (e.g. `{{.UserName}}`). | +| `spec.variables[].required` | boolean | Yes | Whether the variable must be provided when rendering the template. | +| `spec.variables[].type` | string | Yes | A hint about the expected value of this variable. One of `string` or `url`. | + +## Status fields (read-only) + +| Field | Type | Description | +| --- | --- | --- | +| `status.conditions` | []Object | Latest available observations of the template's current state, indicating whether it is ready for use. | + +## Usage + +```yaml +apiVersion: notification.miloapis.com/v1alpha1 +kind: EmailTemplate +metadata: + name: welcome-email +spec: + subject: "Welcome to Datum Cloud, {{.UserName}}" + htmlBody: "

Hello {{.UserName}}, visit your dashboard to get started.

" + textBody: "Hello {{.UserName}}, visit {{.DashboardURL}} to get started." + variables: + - name: UserName + required: true + type: string + - name: DashboardURL + required: true + type: url +``` + +```bash +datumctl apply -f emailtemplate.yaml +datumctl get emailtemplates +datumctl describe emailtemplate welcome-email +``` + + + Run `datumctl explain emailtemplates --recursive` to see the full, live field tree for this resource. + diff --git a/api/notification/overview.mdx b/api/notification/overview.mdx new file mode 100644 index 0000000..29be56f --- /dev/null +++ b/api/notification/overview.mdx @@ -0,0 +1,38 @@ +--- +title: "Notification" +sidebarTitle: "Overview" +description: "Contacts, contact groups, and email delivery on Datum Cloud — the notification.miloapis.com service." +--- + +Datum Cloud manages notification recipients and email delivery through the `notification.miloapis.com` API. You declare the people you contact, organize them into reusable groups, and send email — either one message or a broadcast to a group, optionally rendered from a shared template. Contacts, groups, memberships, and email resources are all created with `datumctl apply -f` and read with `datumctl get` and `datumctl describe`. + + + The Notification API is **alpha** (`v1alpha1`). Fields and behavior may change in backward-incompatible ways between releases. + + +## Resources + + + + A single notification recipient, including their email address and identifying details. + + + A named, reusable group of contacts you can target as a broadcast audience. + + + Associates a contact with a contact group. + + + A single email message sent to a recipient. + + + An email sent to every contact in a contact group. + + + +**Platform-provided:** the [EmailTemplate](/api/notification/emailtemplate) used to render an email lives under [Platform resources](/api/platform/overview). + +## Learn more + +- [API resources overview](/api/overview) — the resource reference landing page across all Datum Cloud services. +- [Changing resources](/datumctl/resources/changing) — how to apply, edit, and safely preview changes to these resources. diff --git a/api/overview.mdx b/api/overview.mdx new file mode 100644 index 0000000..c438995 --- /dev/null +++ b/api/overview.mdx @@ -0,0 +1,121 @@ +--- +title: "API resources" +sidebarTitle: "Overview" +description: "The resource and field reference for Datum Cloud services." +--- + +This section is the **resource and field reference** for Datum Cloud. It documents the resources each service exposes and the fields you set and read on them — what a resource *is*, not how to accomplish a task with it. + + + Looking for how-to guides instead? Here's how the references fit together: + + - **API resources** (you are here) — the resource/field reference: what fields a resource has, their types, and what they mean. + - **[datumctl](/datumctl/overview)** — task-oriented how-to guides for using the CLI. Run `datumctl --help` for the command and flag reference. + + + + The Datum Cloud API is currently **alpha** (`v1alpha`/`v1alpha1`). Resources, fields, and defaults may change in backward-incompatible ways between releases. + + +## Start with the concepts + +Every Datum Cloud resource shares the same shape and workflow, so a handful of ideas apply to *all* of them. Read these first and the per-service pages become quick lookups rather than fresh material each time. + + + + The declarative model behind every resource — `apiVersion`, `kind`, `metadata`, `spec`, and `status`. Start here. + + + The shared `metadata` block: names, labels, annotations, and the fields the platform manages for you. + + + How to read observed state and the standard `conditions` pattern to tell whether a resource is ready. + + + Whether a resource lives inside a **Project** or is shared across the **Platform**, and how that maps to your context. + + + + + Three more concept pages round out the shared model: [versioning & stability](/api/concepts/versioning), [resource references](/api/concepts/references), [field formats & types](/api/concepts/field-formats), and [validation & safe changes](/api/concepts/validation). + + +## Browse by service + +Resources are organized by the service that owns them. Services group into three layers: **Foundation** services model who you are and what you own, **Infrastructure** services run and connect your workloads, and **Operations** services govern consumption, billing, and communication. + +### Foundation + +Model your organizations, projects, access control, and machine identities. + + + + Organizations, projects, and the membership that ties people to them. + + + Roles, policy bindings, groups, service accounts, and user invitations that control access. + + + +### Infrastructure + +Run workloads and connect them to the network. + + + + Workloads, deployments, and the instances that run them. + + + Networks, subnets, gateways, and HTTP routing resources. + + + Managed DNS zones and records for your domains. + + + IP pools, claims, and allocations for address management. + + + +### Operations + +Govern consumption, pay for what you use, and stay informed. + + + + Allowance buckets, resource claims, and grants that meter usage. + + + Billing accounts, account bindings, and payment methods. + + + Export policies that ship metrics and logs to your own tooling. + + + Contacts, contact groups, and the emails and broadcasts sent to them. + + + + + **[Platform resources](/api/platform/overview)** collects the platform-provided and reference resources you point at rather than compose — the service catalog (Services, entitlements, and consumers), classes like `DNSZoneClass` and `GatewayClass`, `IPPool`s that claims allocate from, and email templates. + + +## How to read these pages + +Each resource page follows the same structure, and each part is explained in depth on its concept page: + +- **Identity** — the resource's kind, [API group and version](/api/concepts/versioning), and [scope](/api/concepts/scopes) (**Project** or **Platform**). +- **Spec fields** — the fields you set to declare desired state. See [API conventions](/api/concepts/conventions) for the `spec`/`status` model, [field formats & types](/api/concepts/field-formats) for how the `Type` and `Required` columns read, and [object metadata](/api/concepts/metadata) for the shared `metadata` block every page omits. +- **Status** — the read-only fields the platform reports back, including the shared [status & conditions](/api/concepts/status-and-conditions) pattern. Fields that point at other resources follow the [resource references](/api/concepts/references) convention. +- **Usage** — how to create, read, and inspect the resource with `datumctl`. + +Manifests are applied with `datumctl apply -f`, and you can read or inspect resources with `datumctl get` and `datumctl describe` — see [changing resources](/datumctl/resources/changing) and [reading resources](/datumctl/resources/reading). Every write is checked first; see [validation & safe changes](/api/concepts/validation). + +```bash +datumctl apply -f my-resource.yaml +datumctl get +datumctl describe +``` + + + Field types and required markers throughout this reference come straight from the live API schema, which you can also explore from the CLI with `datumctl explain`. + diff --git a/api/platform/overview.mdx b/api/platform/overview.mdx new file mode 100644 index 0000000..6dc8dc8 --- /dev/null +++ b/api/platform/overview.mdx @@ -0,0 +1,58 @@ +--- +title: "Platform resources" +sidebarTitle: "Overview" +description: "Platform-provided and reference resources — the service catalog, classes and pools other resources point at, and email templates you read or reference rather than create." +--- + +This section collects Datum Cloud's **platform-provided and reference resources**: things Datum operates or publishes that you typically **read or reference** rather than create. They include the service catalog, the classes that other resources point at (such as a DNS zone class or a gateway class), the address pools that back IP allocation, and the email templates that shape platform notifications. + +These differ from the resources you create and manage day to day inside a Project — networks, DNS zones, gateways, workloads, and the like. Those are documented across the rest of the reference; see the [API resources overview](/api/overview) for the full picture. The pages below describe the shared, upstream pieces you consume: you reference a class by name, opt in to a service, or draw addresses from a pool, but the resource itself is provided for you. + + + These APIs are currently **alpha** (`v1alpha`/`v1alpha1`). Resources, fields, and defaults may change in backward-incompatible ways between releases. + + +## Service catalog + +The catalog of managed capabilities Datum offers, the entitlements you create to use them, and the consumer records providers see. + + + + The platform-owned identity record for a managed capability, keyed by its canonical `serviceName`. + + + Created in your Project to opt in to a service; one per service you want to use. + + + The provider's view of an entitlement, reflected into the provider Project for approval and tracking. + + + +## Reference classes & pools + +Classes and pools are provided by the platform and referenced by name from the resources you create — pick a class or pool, and Datum supplies the implementation behind it. + + + + The class a DNS zone references to select how the platform hosts and serves it. + + + The class a gateway references to select its platform-provided implementation. + + + The address pools that back IP claims and allocations in your Project. + + + +## Templates + + + + The reusable email content the platform renders when it sends notifications. + + + +## Learn more + +- [API resources overview](/api/overview) — the resource reference landing page across all Datum Cloud services. +- [Scopes](/api/concepts/scopes) — whether a resource lives inside a **Project** or is shared across the **Platform**. diff --git a/api/quota/allowancebucket.mdx b/api/quota/allowancebucket.mdx new file mode 100644 index 0000000..2b3429a --- /dev/null +++ b/api/quota/allowancebucket.mdx @@ -0,0 +1,79 @@ +--- +title: "AllowanceBucket" +sidebarTitle: "AllowanceBucket" +description: "AllowanceBucket aggregates quota limits and usage for a single (consumer, resourceType) combination." +--- + + + API resource reference for **AllowanceBucket**, part of the [Quota service](/api/quota/overview). To create or change one, see [Changing resources](/datumctl/resources/changing); to inspect, see [Reading resources](/datumctl/resources/reading). + + + + This resource is part of the `v1alpha1` API and is subject to change. Fields and behavior may change in future releases. + + +## Identity + +| | | +| --- | --- | +| Group | `quota.miloapis.com` | +| Version | `v1alpha1` | +| Kind | `AllowanceBucket` | +| Scope | Project | + +## Overview + +An `AllowanceBucket` aggregates quota capacity and consumption for a single (consumer, resource type) pair. The quota system creates one bucket automatically for each unique combination found in active `ResourceGrant` resources, then continuously tallies the total granted capacity (`limit`) against the amount consumed by granted `ResourceClaim` resources (`allocated`) to compute what remains (`available`). + +You typically do not create buckets by hand — they are system-managed and read-mostly. You use them to see how much quota a consumer has, how much is in use, and how much is left, which drives real-time admission decisions when new `ResourceClaim` resources are created. + +## Spec fields + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `spec.consumerRef` | Object | Yes | Identifies the quota consumer this bucket tracks. Must match the consumer on the `ResourceGrant` resources that contribute to the bucket. | +| `spec.consumerRef.kind` | string | Yes | Type of consumer resource, e.g. `Organization`, `Project`, or `User`. | +| `spec.consumerRef.name` | string | Yes | Name of the specific consumer instance, e.g. `acme-corp`. | +| `spec.consumerRef.apiGroup` | string | No | API group of the consumer resource, e.g. `resourcemanager.miloapis.com`. | +| `spec.consumerRef.namespace` | string | No | Namespace of the consumer resource; required for Project-scoped consumers, left empty for Organization-scoped consumers. | +| `spec.resourceType` | string | Yes | The resource type this bucket aggregates quota for. Must match a registered `ResourceRegistration` resource type, e.g. `resourcemanager.miloapis.com/projects`. | + +## Status fields (read-only) + +| Field | Type | Description | +| --- | --- | --- | +| `status.limit` | integer | Total quota capacity for this (consumer, resource type), summed from all active contributing `ResourceGrant` resources. | +| `status.allocated` | integer | Total quota currently consumed by granted `ResourceClaim` resources. | +| `status.available` | integer | Remaining capacity, computed as `limit - allocated` (never negative); drives admission decisions. | +| `status.claimCount` | integer | Number of granted `ResourceClaim` resources consuming from this bucket. | +| `status.grantCount` | integer | Number of active `ResourceGrant` resources contributing to this bucket's limit. | +| `status.contributingGrantRefs` | []Object | Per-grant detail (`name`, `amount`, `lastObservedGeneration`) for each `ResourceGrant` that contributes capacity. | +| `status.lastReconciliation` | string | Timestamp of the last recalculation; indicates how fresh the aggregated data is. | +| `status.observedGeneration` | integer | Most recent spec generation the quota system has processed. | + +## Usage + +Buckets are normally created automatically, but the spec is small enough to inspect or reproduce directly: + +```yaml +apiVersion: quota.miloapis.com/v1alpha1 +kind: AllowanceBucket +metadata: + name: acme-corp-projects +spec: + consumerRef: + apiGroup: resourcemanager.miloapis.com + kind: Organization + name: acme-corp + resourceType: resourcemanager.miloapis.com/projects +``` + +```bash +datumctl apply -f allowancebucket.yaml --project my-project +datumctl get allowancebuckets --project my-project +datumctl describe allowancebuckets acme-corp-projects --project my-project +``` + + + Run `datumctl explain allowancebuckets --recursive` to see the full, live field tree for this resource. + diff --git a/api/quota/overview.mdx b/api/quota/overview.mdx new file mode 100644 index 0000000..60710d6 --- /dev/null +++ b/api/quota/overview.mdx @@ -0,0 +1,40 @@ +--- +title: "Quota" +sidebarTitle: "Overview" +description: "Resource allowances, claims, and grants that govern usage on Datum Cloud — the quota.miloapis.com API." +--- + +Datum Cloud governs how much of each resource type a consumer may use through the `quota.miloapis.com` API. Capacity is allocated to a consumer with a **ResourceGrant**, individual requests draw against that capacity with a **ResourceClaim**, and an **AllowanceBucket** continuously aggregates the two to report how much remains available for admission decisions. + + + The quota API is **alpha** (`v1alpha1`). Fields and behavior may change in backward-incompatible ways between releases. + + +## Resources + + + + Aggregates quota limits and usage for a single consumer and resource type, reporting the capacity still available. + + + Requests quota allocation when a resource is created, consuming capacity from the matching bucket. + + + Allocates quota capacity to a consumer for specific resource types, supplying the allowances buckets aggregate. + + + +## How the pieces fit together + +- A **ResourceGrant** grants a consumer capacity for one or more resource types. Only grants with an `Active` status contribute to available quota. +- An **AllowanceBucket** is created automatically for each unique consumer and resource type. It sums capacity from active grants and consumption from granted claims, then reports the remaining `status.available`. +- A **ResourceClaim** requests an allocation for a resource type. The quota system checks the matching bucket's available capacity to decide whether the claim can be granted. + + + Inspect the exact fields for any resource with `datumctl explain`, for example `datumctl explain allowancebuckets.spec` or `datumctl explain resourceclaims.spec`. + + +## Learn more + +- [API resources overview](/api/overview) — the resource reference landing page across all Datum Cloud services. +- [Changing resources](/datumctl/resources/changing) — how to apply, edit, and safely preview changes to these resources. diff --git a/api/quota/resourceclaim.mdx b/api/quota/resourceclaim.mdx new file mode 100644 index 0000000..c5d5750 --- /dev/null +++ b/api/quota/resourceclaim.mdx @@ -0,0 +1,97 @@ +--- +title: "ResourceClaim" +sidebarTitle: "ResourceClaim" +description: "ResourceClaim requests quota allocation during resource creation, consuming quota capacity from AllowanceBuckets." +--- + + + API resource reference for **ResourceClaim**, part of the [Quota service](/api/quota/overview). To create or change one, see [Changing resources](/datumctl/resources/changing); to inspect, see [Reading resources](/datumctl/resources/reading). + + + + This resource is part of the `v1alpha1` API and is subject to change. Fields and behavior may change in future releases. + + +## Identity + +| | | +| --- | --- | +| Group | `quota.miloapis.com` | +| Version | `v1alpha1` | +| Kind | `ResourceClaim` | +| Scope | Project | + +## Overview + +A `ResourceClaim` requests quota allocation when a resource is created. Each claim consumes quota capacity from the matching `AllowanceBucket` and links back to the resource that triggered it, so quota usage can be tracked, audited, and cleaned up over its lifecycle. + +Most claims are created automatically by a `ClaimCreationPolicy` during admission, but administrators can also create them by hand for testing or special allocation scenarios. All requests in a single claim are evaluated atomically: either every request has sufficient quota and the whole claim is granted, or any shortage denies the entire claim. Once granted, a claim reserves the requested amounts until it is deleted. + +## Spec fields + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `spec.requests` | []Object | Yes | The resource types and amounts being claimed. Minimum 1, maximum 20 requests per claim; each resource type may appear only once. Processed atomically. | +| `spec.requests[].resourceType` | string | Yes | Identifies the resource type being claimed. Must exactly match an active `ResourceRegistration.spec.resourceType` (e.g. `resourcemanager.miloapis.com/projects`, `compute_cpu`). | +| `spec.requests[].amount` | integer | Yes | How much quota to claim, measured in the BaseUnit from the `ResourceRegistration`. Use `1` for single instances (Entity registrations) or a capacity value for Allocation registrations. | +| `spec.consumerRef` | Object | No | Identifies the quota consumer making the claim. Can be omitted when created via `ClaimCreationPolicy` (auto-filled from the authenticated context). | +| `spec.consumerRef.kind` | string | Yes* | Type of consumer resource (e.g. `Organization`, `Project`, `User`). Required when `consumerRef` is set. | +| `spec.consumerRef.name` | string | Yes* | Name of the specific consumer instance. Required when `consumerRef` is set. | +| `spec.consumerRef.apiGroup` | string | No | API group of the consumer resource (e.g. `resourcemanager.miloapis.com`, `iam.miloapis.com`). | +| `spec.consumerRef.namespace` | string | No | Scope of the consumer resource. Required for Project-scoped consumers (e.g. Projects); empty for Platform-scoped consumers (e.g. Organizations). | +| `spec.resourceRef` | Object | No | Identifies the resource that triggered this claim. Auto-populated by `ClaimCreationPolicy` during admission. | +| `spec.resourceRef.kind` | string | Yes* | Type of the referenced resource (e.g. `Project`, `User`, `Organization`). Required when `resourceRef` is set. | +| `spec.resourceRef.name` | string | Yes* | Name of the specific triggering resource instance. Required when `resourceRef` is set. | +| `spec.resourceRef.apiGroup` | string | No | API group of the referenced resource (e.g. `resourcemanager.miloapis.com`). | +| `spec.resourceRef.namespace` | string | No | Scope containing the referenced resource. Required for Project-scoped resources, omitted for Platform-scoped ones. | + + + Fields marked Yes* are required only when their parent object (`consumerRef` or `resourceRef`) is present. + + +## Status fields (read-only) + +| Field | Type | Description | +| --- | --- | --- | +| `status.conditions` | []Object | Overall claim evaluation status. The `Granted` condition indicates approval, with reasons such as `QuotaAvailable`, `QuotaExceeded`, `ValidationFailed`, or `PendingEvaluation`. | +| `status.allocations` | []Object | Per-request allocation detail, one entry per `spec.requests` item, indexed by resource type. | +| `status.allocations[].resourceType` | string | Which request this allocation describes; matches a `spec.requests[].resourceType`. | +| `status.allocations[].status` | string | Allocation result for this request: `Granted`, `Denied`, or `Pending`. | +| `status.allocations[].allocatedAmount` | integer | How much quota was allocated. Equals the requested amount when granted, `0` when denied or pending. | +| `status.allocations[].allocatingBucket` | string | Name of the `AllowanceBucket` that provided the quota. Set only when granted. | +| `status.allocations[].reason` | string | Machine-readable status reason (e.g. `QuotaAvailable`, `QuotaExceeded`, `ValidationFailed`). | +| `status.allocations[].message` | string | Human-readable explanation of the allocation result. | +| `status.allocations[].lastTransitionTime` | string | When this allocation status last changed. | +| `status.observedGeneration` | integer | Most recent spec generation the system has processed. | + +## Usage + +```yaml +apiVersion: quota.miloapis.com/v1alpha1 +kind: ResourceClaim +metadata: + name: web-app-project-claim +spec: + consumerRef: + apiGroup: resourcemanager.miloapis.com + kind: Organization + name: acme-corp + resourceRef: + apiGroup: resourcemanager.miloapis.com + kind: Project + name: web-app-project + namespace: acme-corp + requests: + - resourceType: resourcemanager.miloapis.com/projects + amount: 1 +``` + +```bash +datumctl apply -f resourceclaim.yaml --project my-project +datumctl get resourceclaims --project my-project +datumctl describe resourceclaim web-app-project-claim --project my-project +``` + + + Run `datumctl explain resourceclaims --recursive` to see the full, live field tree for this resource. + diff --git a/api/quota/resourcegrant.mdx b/api/quota/resourcegrant.mdx new file mode 100644 index 0000000..ca5499d --- /dev/null +++ b/api/quota/resourcegrant.mdx @@ -0,0 +1,79 @@ +--- +title: "ResourceGrant" +sidebarTitle: "ResourceGrant" +description: "ResourceGrant allocates quota capacity to a consumer for specific resource types." +--- + + + API resource reference for **ResourceGrant**, part of the [Quota service](/api/quota/overview). To create or change one, see [Changing resources](/datumctl/resources/changing); to inspect, see [Reading resources](/datumctl/resources/reading). + + + + This resource is part of the `v1alpha1` API and is subject to change. Fields and behavior may change in future releases. + + +## Identity + +| | | +| --- | --- | +| Group | `quota.miloapis.com` | +| Version | `v1alpha1` | +| Kind | `ResourceGrant` | +| Scope | Project | + +## Overview + +A `ResourceGrant` allocates quota capacity to a consumer (such as an Organization, Project, or User) for one or more resource types. Each grant lists the allowances it provides, and the quota system aggregates capacity from all active grants into allowance buckets that resource claims then draw against. + +Use a `ResourceGrant` to hand out quota: define base allocations for a consumer, add extra capacity for a specific tier, or express incremental increases over time. Grants can be created directly by an administrator or generated automatically by a policy. When the quota system validates a grant successfully, it marks the grant `Active` and its allowances begin contributing to quota decisions; grants that fail validation do not contribute until corrected. + +## Spec fields + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `spec.allowances` | []Object | Yes | The quota allocations provided by this grant. Minimum 1, maximum 20 allowances. All allowances share the same consumer and activate or deactivate together with the grant. | +| `spec.allowances[].resourceType` | string | Yes | Identifies the resource type receiving the allocation. Must exactly match the resource type of an active `ResourceRegistration` (e.g. `resourcemanager.miloapis.com/projects`, `compute_cpu`, `storage.volumes`). | +| `spec.allowances[].buckets` | []Object | Yes | Individual allocations for this resource type. All bucket amounts are summed to determine the total allowance. Minimum 1 bucket required. | +| `spec.allowances[].buckets[].amount` | integer | Yes | Capacity provided by this bucket, measured in the BaseUnit of the corresponding `ResourceRegistration`. Must be a non-negative integer (0 is valid but provides no quota). | +| `spec.consumerRef` | Object | Yes | Identifies the quota consumer that receives these allowances. The consumer type must match the consumer type expected by each allowance's `ResourceRegistration`. | +| `spec.consumerRef.kind` | string | Yes | Type of consumer resource, such as `Organization`, `Project`, or `User`. | +| `spec.consumerRef.name` | string | Yes | Name of the specific consumer resource instance (e.g. `acme-corp`, `web-application`). | +| `spec.consumerRef.apiGroup` | string | No | API group of the consumer resource (e.g. `resourcemanager.miloapis.com`, `iam.miloapis.com`). | +| `spec.consumerRef.namespace` | string | No | Scope of the consumer resource. Set for Project-scoped consumers; leave empty for Platform-scoped consumers such as Organizations. | + +## Status fields (read-only) + +| Field | Type | Description | +| --- | --- | --- | +| `status.conditions` | []Object | Latest observations of the grant's state. The `Active` condition indicates whether the grant is validated and contributing capacity to allowance buckets; when `False`, the condition message reports the validation error. | +| `status.observedGeneration` | integer | The most recent spec generation the quota system has processed. When it matches `metadata.generation`, the status reflects the current spec; a lower value means changes are still being processed. | + +## Usage + +```yaml +apiVersion: quota.miloapis.com/v1alpha1 +kind: ResourceGrant +metadata: + name: acme-corp-project-quota +spec: + consumerRef: + apiGroup: resourcemanager.miloapis.com + kind: Organization + name: acme-corp + allowances: + - resourceType: resourcemanager.miloapis.com/projects + buckets: + - amount: 100 +``` + +```bash +datumctl apply -f resourcegrant.yaml --project my-project +datumctl get resourcegrants --project my-project +datumctl describe resourcegrant acme-corp-project-quota --project my-project +``` + + + Run `datumctl explain resourcegrants --recursive` to see the full, live field tree for this resource. + + + diff --git a/api/resource-manager/organization.mdx b/api/resource-manager/organization.mdx new file mode 100644 index 0000000..14ffcb7 --- /dev/null +++ b/api/resource-manager/organization.mdx @@ -0,0 +1,60 @@ +--- +title: "Organization" +sidebarTitle: "Organization" +description: "Organization is the Schema for the Organizations API." +--- + + + API resource reference for **Organization**, part of the [Resource Manager service](/api/resource-manager/overview). To create or change one, see [Changing resources](/datumctl/resources/changing); to inspect, see [Reading resources](/datumctl/resources/reading). + + + + This resource is part of the `v1alpha1` API and is subject to change. Fields and behavior may change in future releases. + + +## Identity + +| | | +| --- | --- | +| Group | `resourcemanager.miloapis.com` | +| Version | `v1alpha1` | +| Kind | `Organization` | +| Scope | Platform | + +## Overview + +An `Organization` is the top-level container in Datum Cloud that owns projects, members, and billing. Because it is Platform-scoped, it exists across the whole platform rather than inside a single project. Use it to establish an organizational boundary — either a `Personal` organization tied to an individual account, or a `Standard` organization for a team or company. + +## Spec fields + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `spec.type` | string | Yes | The type of organization. One of `Personal` or `Standard`. | + +## Status fields (read-only) + +| Field | Type | Description | +| --- | --- | --- | +| `status.conditions` | []Object | Observations of the organization's current state. Known condition types include `Ready`. | +| `status.observedGeneration` | integer | The most recent generation observed for this Organization by the controller. | + +## Usage + +```yaml +apiVersion: resourcemanager.miloapis.com/v1alpha1 +kind: Organization +metadata: + name: acme +spec: + type: Standard +``` + +```bash +datumctl apply -f organization.yaml +datumctl get organizations +datumctl describe organization acme +``` + + + Run `datumctl explain organizations --recursive` to see the full, live field tree for this resource. + diff --git a/api/resource-manager/organizationmembership.mdx b/api/resource-manager/organizationmembership.mdx new file mode 100644 index 0000000..b54670b --- /dev/null +++ b/api/resource-manager/organizationmembership.mdx @@ -0,0 +1,77 @@ +--- +title: "OrganizationMembership" +sidebarTitle: "OrganizationMembership" +description: "OrganizationMembership establishes a user's membership in an organization and optionally assigns roles to grant permissions." +--- + + + API resource reference for **OrganizationMembership**, part of the [Resource Manager service](/api/resource-manager/overview). To create or change one, see [Changing resources](/datumctl/resources/changing); to inspect, see [Reading resources](/datumctl/resources/reading). + + + + This resource is part of the `v1alpha1` API and is subject to change. Fields and behavior may change in future releases. + + +## Identity + +| | | +| --- | --- | +| Group | `resourcemanager.miloapis.com` | +| Version | `v1alpha1` | +| Kind | `OrganizationMembership` | +| Scope | Project | + +## Overview + +An `OrganizationMembership` connects a user to an organization and, optionally, grants that user one or more roles within it. Creating a membership establishes the user-organization relationship; listing roles on the membership grants the corresponding permissions. + +Use it whenever you want to add someone to an organization or adjust what they can do there. When you assign roles, the controller automatically creates and manages the underlying `PolicyBinding` resources for each role, so you manage access in one place. Roles can be added or removed at any time after the membership exists. The referenced user, organization, and roles must already exist before you create the membership. + +## Spec fields + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `spec.organizationRef` | Object | Yes | Identifies the organization to grant membership in. The organization must exist beforehand. | +| `spec.organizationRef.name` | string | Yes | Name of the referenced organization. | +| `spec.userRef` | Object | Yes | Identifies the user to grant organization membership. The user must exist beforehand. | +| `spec.userRef.name` | string | Yes | Name of the referenced user. | +| `spec.roles` | []Object | No | List of roles to assign to the user within the organization. Omit or leave empty to establish membership with no roles. Duplicate roles are rejected. | +| `spec.roles[].name` | string | Yes | Name of the referenced role. | +| `spec.roles[].namespace` | string | No | Location of the referenced role. Defaults to the membership's own location if not set. | + +## Status fields (read-only) + +| Field | Type | Description | +| --- | --- | --- | +| `status.appliedRoles` | []Object | Per-role reconciliation state for each entry in `spec.roles`. Each entry records `name`, `namespace`, `status` (`Applied`, `Pending`, or `Failed`), a `policyBindingRef` and `appliedAt` timestamp when applied, and a `message` explaining failures. | +| `status.conditions` | []Object | Tracks state such as `Ready` (membership established) and `RolesApplied` (whether all roles were successfully applied). | +| `status.observedGeneration` | integer | The most recent membership spec generation the controller has processed. | +| `status.organization` | Object | Cached information about the referenced organization, populated by the controller. | +| `status.user` | Object | Cached information about the referenced user, populated by the controller. | + +## Usage + +```yaml +apiVersion: resourcemanager.miloapis.com/v1alpha1 +kind: OrganizationMembership +metadata: + name: jane-acme-membership +spec: + organizationRef: + name: acme-corp + userRef: + name: jane-doe + roles: + - name: organization-viewer + namespace: organization-acme-corp +``` + +```bash +datumctl apply -f organizationmembership.yaml --project my-project +datumctl get organizationmemberships --project my-project +datumctl describe organizationmembership jane-acme-membership --project my-project +``` + + + Run `datumctl explain organizationmemberships --recursive` to see the full, live field tree for this resource. + diff --git a/api/resource-manager/overview.mdx b/api/resource-manager/overview.mdx new file mode 100644 index 0000000..d90735a --- /dev/null +++ b/api/resource-manager/overview.mdx @@ -0,0 +1,30 @@ +--- +title: "Resource Manager" +sidebarTitle: "Overview" +description: "Organizations and projects — the top-level containers for everything you run on Datum Cloud." +--- + +Datum Cloud groups everything you build under the `resourcemanager.miloapis.com` API. An **Organization** is the top-level container that owns billing, membership, and access; a **Project** lives within an organization and holds the resources you actually run — DNS zones, networks, and more. **OrganizationMembership** connects a user to an organization and assigns the roles that grant them access. Together these form the container hierarchy that every other Datum Cloud resource lives inside. + + + The Resource Manager API is **alpha** (`v1alpha1`). Fields and behavior may change in backward-incompatible ways between releases. + + +## Resources + + + + The top-level container that owns billing, membership, and access for everything beneath it. + + + A container within an organization that holds the resources you run on Datum Cloud. + + + Connects a user to an organization and assigns the roles that grant them access. + + + +## Learn more + +- [API resources overview](/api/overview) — the resource reference landing page across all Datum Cloud services. +- [Changing resources](/datumctl/resources/changing) — how to apply, edit, and safely preview changes to these resources. diff --git a/api/resource-manager/project.mdx b/api/resource-manager/project.mdx new file mode 100644 index 0000000..c6ace4d --- /dev/null +++ b/api/resource-manager/project.mdx @@ -0,0 +1,63 @@ +--- +title: "Project" +sidebarTitle: "Project" +description: "Project is the Schema for the projects API." +--- + + + API resource reference for **Project**, part of the [Resource Manager service](/api/resource-manager/overview). To create or change one, see [Changing resources](/datumctl/resources/changing); to inspect, see [Reading resources](/datumctl/resources/reading). + + + + This resource is part of the `v1alpha1` API and is subject to change. Fields and behavior may change in future releases. + + +## Identity + +| | | +| --- | --- | +| Group | `resourcemanager.miloapis.com` | +| Version | `v1alpha1` | +| Kind | `Project` | +| Scope | Platform | + +## Overview + +A `Project` is a top-level container that groups related Datum Cloud resources — such as DNS zones, networking, and other workloads — under a single owning organization. Most Project-scoped resources live inside a Project, and you select one with the `--project` flag when reading or applying manifests. Use a Project to organize resources by team, environment, or application, all owned by an `Organization`. + +## Spec fields + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `spec.ownerRef` | Object | Yes | Reference to the owner of the project. Must be a valid resource. | +| `spec.ownerRef.kind` | string | Yes | Kind of the owning resource. Must be `Organization`. | +| `spec.ownerRef.name` | string | Yes | Name of the owning resource. | + +## Status fields (read-only) + +| Field | Type | Description | +| --- | --- | --- | +| `status.conditions` | []Object | Observations of the project's current state. Known condition types include `Ready`. | + +## Usage + +```yaml +apiVersion: resourcemanager.miloapis.com/v1alpha1 +kind: Project +metadata: + name: my-project +spec: + ownerRef: + kind: Organization + name: my-organization +``` + +```bash +datumctl apply -f project.yaml +datumctl get projects +datumctl describe project my-project +``` + + + Run `datumctl explain projects --recursive` to see the full, live field tree for this resource. + diff --git a/api/services/service.mdx b/api/services/service.mdx new file mode 100644 index 0000000..23c98d4 --- /dev/null +++ b/api/services/service.mdx @@ -0,0 +1,83 @@ +--- +title: "Service" +sidebarTitle: "Service" +description: "Service is the Schema for the services API. It is the platform-owned identity record for a managed service offered on Datum." +--- + + + **Platform-provided resource.** Datum operates this resource; you typically reference or read it rather than create it. See [Platform resources](/api/platform/overview). + + + + API resource reference for **Service**, part of the platform service catalog. See [Platform resources](/api/platform/overview) for the full catalog. To read or inspect, see [Reading resources](/datumctl/resources/reading). + + + + This resource is part of the `v1alpha1` API and is subject to change. Fields and behavior may change in future releases. + + +## Identity + +| | | +| --- | --- | +| Group | `services.miloapis.com` | +| Version | `v1alpha1` | +| Kind | `Service` | +| Scope | Platform | + +## Overview + +A `Service` is the platform-owned identity record for a managed capability a provider offers on Datum Cloud. It holds everything consumer-facing: the canonical name, display name, description, owning producer project, and lifecycle phase. Runtime concerns such as deployments, images, endpoints, and routing stay in the provider's own repository; this resource is identity only. + +The canonical identifier is `spec.serviceName`, a reverse-DNS name (for example, `compute.miloapis.com`) that appears on invoices, in the portal, and in every downstream reference. Once a service is Published, `serviceName` is locked: breaking changes ship as a new `Service` with a new `serviceName` and a coordinated migration rather than a silent mutation. Use a `Service` to register a capability so downstream governance resources (such as MeterDefinition and MonitoredResourceType) and consumers (quota, marketplace, entitlements) can reference it. + +## Spec fields + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `spec.serviceName` | string | Yes | Canonical reverse-DNS identifier (e.g., `compute.miloapis.com`). The cross-system join key used by billing exports and the portal. Immutable. | +| `spec.displayName` | string | Yes | Human-readable name surfaced in the portal, marketplace, and on invoices. Editable over the service's lifetime. | +| `spec.phase` | string | Yes | Provider-declared lifecycle state. Forward-only transitions: `Draft` → `Published` → `Deprecated` → `Retired`. | +| `spec.owner` | Object | Yes | Identifies the producer project that publishes and owns the service. | +| `spec.owner.producerProjectRef` | Object | Yes | Reference to the producer-project resource that owns the service. | +| `spec.owner.producerProjectRef.name` | string | Yes | The `metadata.name` of the owning producer-project resource. | +| `spec.description` | string | No | Plain-English explanation of what the service offers. Editable over the service's lifetime. | +| `spec.enablementPolicy` | Object | No | Controls whether consumers can self-service enable the service or must wait for provider approval. | +| `spec.enablementPolicy.mode` | string | Yes (within object) | Selects the enablement flow for this service. | +| `spec.dependencies` | []Object | No | Services that must be enabled alongside this service; the platform auto-enables any listed dependency not already active in a consumer's project. | +| `spec.dependencies[].serviceRef` | Object | Yes (within object) | Identifies the dependent service. | +| `spec.dependencies[].serviceRef.name` | string | Yes (within object) | The `metadata.name` of the dependent service. | + +## Status fields (read-only) + +| Field | Type | Description | +| --- | --- | --- | +| `status.conditions` | []Object | Latest available observations of the resource's state, including how the controller reflects the declared phase. | +| `status.observedGeneration` | integer | The most recent generation observed by the controller. | +| `status.publishedAt` | string | Time at which the controller first observed the resource in the Published phase; preserved across later transitions to Deprecated and Retired. | + +## Usage + +```yaml +apiVersion: services.miloapis.com/v1alpha1 +kind: Service +metadata: + name: compute +spec: + serviceName: compute.miloapis.com + displayName: Compute + phase: Draft + owner: + producerProjectRef: + name: my-producer-project +``` + +```bash +datumctl apply -f service.yaml --project my-project +datumctl get services.services.miloapis.com --project my-project +datumctl describe services.services.miloapis.com compute --project my-project +``` + + + Run `datumctl explain services.services.miloapis.com --recursive` to see the full, live field tree for this resource. + diff --git a/api/services/serviceconsumer.mdx b/api/services/serviceconsumer.mdx new file mode 100644 index 0000000..041da8b --- /dev/null +++ b/api/services/serviceconsumer.mdx @@ -0,0 +1,83 @@ +--- +title: "ServiceConsumer" +sidebarTitle: "ServiceConsumer" +description: "ServiceConsumer is the Schema for the serviceconsumers API." +--- + + + **Platform-provided resource.** Datum operates this resource; you typically reference or read it rather than create it. See [Platform resources](/api/platform/overview). + + + + API resource reference for **ServiceConsumer**, part of the platform service catalog. See [Platform resources](/api/platform/overview) for the full catalog. To create or change one, see [Changing resources](/datumctl/resources/changing); to inspect, see [Reading resources](/datumctl/resources/reading). + + + + This resource is part of the `v1alpha1` API and is subject to change. Fields and behavior may change in future releases. + + +## Identity + +| | | +| --- | --- | +| Group | `services.miloapis.com` | +| Version | `v1alpha1` | +| Kind | `ServiceConsumer` | +| Scope | Platform | + +## Overview + +A `ServiceConsumer` is the record that links a consumer project to a service it has requested access to. The services controller creates one `ServiceConsumer` in the provider project's control plane for every active or pending service entitlement, so providers never create these directly. + +Instead, providers use this resource to act on access requests for `GatedByProvider` services: they write the `spec.approval` field to approve or deny a request. The controller reflects the outcome in the status, tracking whether the consumer record is pending approval, active, or denied. + +## Spec fields + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `spec.consumerProjectRef` | Object | Yes | Identifies the consumer project that requested access to the service. | +| `spec.consumerProjectRef.name` | string | Yes | Name of the consumer project. | +| `spec.serviceRef` | Object | Yes | Identifies the Service this consumer record is associated with. | +| `spec.serviceRef.name` | string | Yes | Name of the referenced Service. | +| `spec.approval` | Object | No | The provider's decision for `GatedByProvider` services. The controller creates the object; the provider writes only this field. | +| `spec.approval.decision` | string | No | The provider's approval or denial of the consumer request. Required when `spec.approval` is set. | +| `spec.approval.message` | string | No | An optional human-readable explanation of the decision. | + +## Status fields (read-only) + +| Field | Type | Description | +| --- | --- | --- | +| `status.phase` | string | Controller-observed lifecycle state of the consumer record: `PendingApproval`, `Active`, or `Denied`. | +| `status.serviceName` | string | The canonical service identifier (e.g. `compute.datumapis.com`) resolved from `spec.serviceRef` and set by the controller. | +| `status.entitledAt` | string | The time at which this consumer record became `Active`. | +| `status.conditions` | []Object | Latest available observations of the consumer record's state. | +| `status.observedGeneration` | integer | The most recent generation observed by the controller. | + +## Usage + +Because the controller creates the `ServiceConsumer`, providers typically edit an existing record to record an approval decision rather than applying a new one: + +```yaml +apiVersion: services.miloapis.com/v1alpha1 +kind: ServiceConsumer +metadata: + name: acme-compute-consumer +spec: + consumerProjectRef: + name: acme-project + serviceRef: + name: compute + approval: + decision: Approved + message: Approved for production compute access. +``` + +```bash +datumctl apply -f serviceconsumer.yaml +datumctl get serviceconsumers +datumctl describe serviceconsumer acme-compute-consumer +``` + + + Run `datumctl explain serviceconsumers --recursive` to see the full, live field tree for this resource. + diff --git a/api/services/serviceentitlement.mdx b/api/services/serviceentitlement.mdx new file mode 100644 index 0000000..61020ef --- /dev/null +++ b/api/services/serviceentitlement.mdx @@ -0,0 +1,75 @@ +--- +title: "ServiceEntitlement" +sidebarTitle: "ServiceEntitlement" +description: "ServiceEntitlement is the Schema for the serviceentitlements API." +--- + + + **Platform-provided resource.** Datum operates this resource; you typically reference or read it rather than create it. See [Platform resources](/api/platform/overview). + + + + API resource reference for **ServiceEntitlement**, part of the platform service catalog. See [Platform resources](/api/platform/overview) for the full catalog. To create or change one, see [Changing resources](/datumctl/resources/changing); to inspect, see [Reading resources](/datumctl/resources/reading). + + + + This resource is part of the `v1alpha1` API and is subject to change. Fields and behavior may change in future releases. + + +## Identity + +| | | +| --- | --- | +| Group | `services.miloapis.com` | +| Version | `v1alpha1` | +| Kind | `ServiceEntitlement` | +| Scope | Platform | + +## Overview + +A `ServiceEntitlement` records a consumer project's intent to use a specific Datum Cloud service. A project admin creates one `ServiceEntitlement` per service they want to enable. The object is written into the consumer project's control plane, and the services operator reconciles it into the provider project so the requested service becomes available. + +Some services require provider approval before they become active; for those, you can include a human-readable message with your request. Entitlements can also be created automatically when one service depends on another. + +## Spec fields + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `spec.serviceRef` | Object | Yes | Identifies the Service the consumer project wants to enable. | +| `spec.serviceRef.name` | string | Yes | The name of the referenced Service. | +| `spec.requestMessage` | string | No | Optional human-readable message sent to the provider when the service requires approval. | + +## Status fields (read-only) + +| Field | Type | Description | +| --- | --- | --- | +| `status.phase` | string | Controller-observed lifecycle state: `PendingApproval`, `Active`, or `Rejected`. | +| `status.origin` | string | Whether this entitlement was created directly by a consumer admin (`Direct`) or automatically as a dependency of another entitlement (`Dependency`). | +| `status.serviceName` | string | Canonical service identifier resolved from `spec.serviceRef` (e.g., `compute.datumapis.com`), set by the controller on first successful reconcile. | +| `status.entitledAt` | string | The time at which this entitlement became Active. | +| `status.dependencyOf` | string | The `metadata.name` of the ServiceEntitlement that caused this entitlement to be created when origin is `Dependency`. | +| `status.observedGeneration` | integer | The most recent generation observed by the controller. | +| `status.conditions` | []Object | Latest available observations of the entitlement's state. | + +## Usage + +```yaml +apiVersion: services.miloapis.com/v1alpha1 +kind: ServiceEntitlement +metadata: + name: compute-datumapis-com +spec: + serviceRef: + name: compute.datumapis.com + requestMessage: "Enabling compute for the production workloads project." +``` + +```bash +datumctl apply -f serviceentitlement.yaml --project my-project +datumctl get serviceentitlements --project my-project +datumctl describe serviceentitlement compute-datumapis-com --project my-project +``` + + + Run `datumctl explain serviceentitlements --recursive` to see the full, live field tree for this resource. + diff --git a/api/telemetry/exportpolicy.mdx b/api/telemetry/exportpolicy.mdx new file mode 100644 index 0000000..388f46c --- /dev/null +++ b/api/telemetry/exportpolicy.mdx @@ -0,0 +1,84 @@ +--- +title: "ExportPolicy" +sidebarTitle: "ExportPolicy" +description: "ExportPolicy is the Schema for the export policy API." +--- + + + API resource reference for **ExportPolicy**, part of the [Telemetry service](/api/telemetry/overview). To create or change one, see [Changing resources](/datumctl/resources/changing); to inspect, see [Reading resources](/datumctl/resources/reading). + + + + This resource is part of the `v1alpha1` API and is subject to change. Fields and behavior may change in future releases. + + +## Identity + +| | | +| --- | --- | +| Group | `telemetry.miloapis.com` | +| Version | `v1alpha1` | +| Kind | `ExportPolicy` | +| Scope | Project | + +## Overview + +An `ExportPolicy` sends telemetry data collected on the Datum Cloud platform to a third-party telemetry platform. You define one or more **sources** that select which telemetry data to publish, and one or more **sinks** that describe where to send it and how to authenticate. Each sink references the sources it should forward. + +Use an `ExportPolicy` when you want your platform metrics to land in an external observability system, for example by pushing them to an endpoint that speaks the Prometheus Remote Write protocol. The control plane continuously evaluates the deployed exporters and reconciles them to match the policy. Note that delivery is not guaranteed, especially when a sink's endpoint is unavailable, and telemetry matching multiple sources is not de-duplicated. + +## Spec fields + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `spec.sources` | []Object | Yes | The telemetry sources to publish to the configured sinks. Multiple sources may be defined; matching data is not de-duplicated across sources. | +| `spec.sources[].name` | string | Yes | A unique name for the source within the policy. Must be a valid DNS label. | +| `spec.sources[].metrics` | Object | No | Selects metric data to retrieve from the Datum Cloud platform. | +| `spec.sources[].metrics.metricsql` | string | No | A MetricSQL query used to select and filter metric data to publish (e.g. `{service_name="networking.miloapis.com", resource_kind="Gateway"}`). See the [MetricSQL reference](https://docs.victoriametrics.com/metricsql/). | +| `spec.sinks` | []Object | Yes | How telemetry data should be sent to third-party platforms. | +| `spec.sinks[].name` | string | Yes | A name for the sink that is unique within the policy. | +| `spec.sinks[].sources` | []string | Yes | The names of the sources whose data should be sent to this sink. | +| `spec.sinks[].target` | Object | Yes | The target the sink delivers telemetry to. | +| `spec.sinks[].target.prometheusRemoteWrite` | Object | No | Publishes telemetry using the Prometheus Remote Write protocol. | +| `spec.sinks[].target.prometheusRemoteWrite.endpoint` | string | Yes | The HTTP endpoint to publish telemetry data to. | +| `spec.sinks[].target.prometheusRemoteWrite.authentication` | Object | No | How the sink authenticates with the endpoint (e.g. `basicAuth`). | +| `spec.sinks[].target.prometheusRemoteWrite.batch` | Object | Yes | How telemetry is batched before sending. Defaults to every 5 seconds or 500 entries, whichever comes first. | +| `spec.sinks[].target.prometheusRemoteWrite.retry` | Object | Yes | Retry behavior when requests to the endpoint fail. Retries are not guaranteed to succeed if the endpoint is unavailable or misconfigured. | + +## Status fields (read-only) + +| Field | Type | Description | +| --- | --- | --- | +| `status.conditions` | []Object | Summary status for the policy as a whole. Known condition types: `Ready`. | +| `status.sinks` | []Object | Per-sink status information for each configured sink. | + +## Usage + +```yaml +apiVersion: telemetry.miloapis.com/v1alpha1 +kind: ExportPolicy +metadata: + name: gateway-metrics +spec: + sources: + - name: gateway-metrics + metrics: + metricsql: '{service_name="networking.miloapis.com", resource_kind="Gateway"}' + sinks: + - name: prometheus + sources: + - gateway-metrics + target: + prometheusRemoteWrite: + endpoint: https://metrics.example.com/api/v1/write +``` + +```bash +datumctl apply -f exportpolicy.yaml --project my-project +datumctl get exportpolicies --project my-project +datumctl describe exportpolicy gateway-metrics --project my-project +``` + + + Run `datumctl explain exportpolicies --recursive` to see the full, live field tree for this resource. + diff --git a/api/telemetry/overview.mdx b/api/telemetry/overview.mdx new file mode 100644 index 0000000..1f50d55 --- /dev/null +++ b/api/telemetry/overview.mdx @@ -0,0 +1,24 @@ +--- +title: "Telemetry" +sidebarTitle: "Overview" +description: "Telemetry export configuration on Datum Cloud — declare where your metrics, logs, and traces are sent." +--- + +Datum Cloud provides telemetry export configuration through the `telemetry.miloapis.com` API. You declare where telemetry collected from your resources should be sent, and Datum handles delivering it to the configured destination. Export configuration is a Project resource you create with `datumctl apply -f`. + + + The Telemetry API is **alpha** (`v1alpha1`). Fields and behavior may change in backward-incompatible ways between releases. + + +## Resources + + + + Configures how telemetry is exported from a Project to an external destination. + + + +## Learn more + +- [API resources overview](/api/overview) — the resource reference landing page across all Datum Cloud services. +- [Changing resources](/datumctl/resources/changing) — how to apply, edit, and safely preview changes to these resources. diff --git a/docs.json b/docs.json index deb6af9..d8005da 100644 --- a/docs.json +++ b/docs.json @@ -219,6 +219,155 @@ ] } ] + }, + { + "tab": "API resources", + "icon": "boxes-stacked", + "groups": [ + { + "group": "Overview", + "pages": [ + "api/overview" + ] + }, + { + "group": "Concepts", + "pages": [ + "api/concepts/conventions", + "api/concepts/metadata", + "api/concepts/status-and-conditions", + "api/concepts/scopes", + "api/concepts/versioning", + "api/concepts/references", + "api/concepts/field-formats", + "api/concepts/validation" + ] + }, + { + "group": "Resource Manager", + "pages": [ + "api/resource-manager/overview", + "api/resource-manager/organization", + "api/resource-manager/project", + "api/resource-manager/organizationmembership" + ] + }, + { + "group": "IAM", + "pages": [ + "api/iam/overview", + "api/iam/role", + "api/iam/policybinding", + "api/iam/group", + "api/iam/groupmembership", + "api/iam/serviceaccount", + "api/iam/userinvitation" + ] + }, + { + "group": "Compute", + "pages": [ + "api/compute/overview", + "api/compute/workload", + "api/compute/workloaddeployment", + "api/compute/instance" + ] + }, + { + "group": "Networking", + "pages": [ + "api/networking/overview", + "api/networking/network", + "api/networking/subnet", + "api/networking/httpproxy", + "api/networking/domain", + { + "group": "Gateway API", + "pages": [ + "api/networking/gateway/overview", + "api/networking/gateway/gateway", + "api/networking/gateway/httproute", + "api/networking/gateway/backendtlspolicy" + ] + }, + { + "group": "Envoy Gateway", + "pages": [ + "api/networking/envoy/overview", + "api/networking/envoy/backend", + "api/networking/envoy/backendtrafficpolicy", + "api/networking/envoy/httproutefilter", + "api/networking/envoy/securitypolicy" + ] + } + ] + }, + { + "group": "DNS", + "pages": [ + "api/dns/overview", + "api/dns/dnszone", + "api/dns/dnsrecordset" + ] + }, + { + "group": "IPAM", + "pages": [ + "api/ipam/overview", + "api/ipam/ipclaim", + "api/ipam/ipallocation" + ] + }, + { + "group": "Quota", + "pages": [ + "api/quota/overview", + "api/quota/allowancebucket", + "api/quota/resourceclaim", + "api/quota/resourcegrant" + ] + }, + { + "group": "Billing", + "pages": [ + "api/billing/overview", + "api/billing/billingaccount", + "api/billing/billingaccountbinding", + "api/billing/paymentmethod" + ] + }, + { + "group": "Telemetry", + "pages": [ + "api/telemetry/overview", + "api/telemetry/exportpolicy" + ] + }, + { + "group": "Notification", + "pages": [ + "api/notification/overview", + "api/notification/contact", + "api/notification/contactgroup", + "api/notification/contactgroupmembership", + "api/notification/email", + "api/notification/emailbroadcast" + ] + }, + { + "group": "Platform resources", + "pages": [ + "api/platform/overview", + "api/services/service", + "api/services/serviceentitlement", + "api/services/serviceconsumer", + "api/dns/dnszoneclass", + "api/networking/gateway/gatewayclass", + "api/ipam/ippool", + "api/notification/emailtemplate" + ] + } + ] } ] }, @@ -299,4 +448,4 @@ "prefill": false } } -} \ No newline at end of file +}