releases
Releases are signed bcd builds the platform may roll out to its nodes. A release is registered from a signed manifest, which must verify under the release key pins given to `rolloutModule`, and rollouts can then target its version. Both methods decide `compute:fleet:admin` on the fleet scope. See [Rollouts](/docs/guides/rollouts).
Releases are signed bcd builds the platform may roll out to its nodes. A release is registered from a signed manifest, which must verify under the release key pins given to rolloutModule, and rollouts can then target its version. Both methods decide compute:fleet:admin on the fleet scope. See Rollouts.
All 2 methods are served by this release.
| Method | Kind | Authorization | Phase | Status |
|---|---|---|---|---|
register | mutation | compute:fleet:admin @ compute-fleet | v0.4 | registered |
list | read | compute:fleet:admin @ compute-fleet | v0.4 | registered |
register
POST /api/compute/releases/register
Verifies a signed bcd release manifest under the configured release pins and records the release; returns it with its per-platform binaries.
-
Replay. Registering a manifest whose version is already recorded with the same sequence returns the stored release; the same version with another sequence is
CONFLICT. -
Errors.
INVALID_INPUTwhen the manifest does not verify (details.reasonsays why), when its sequence is not above the latest registered one (a rollback of the release channel,details.reasonisrollback), when it lists several binaries for one platform, or when it lists no Linux binary. -
Kind: mutation
-
Authorization:
compute:fleet:admin@compute-fleet -
Module:
rollout -
Phase: v0.4 (registered)
Input
| Field | Type | Required | Constraints |
|---|---|---|---|
tenantId | string | yes | at most 128 characters; matches ^[A-Za-z0-9._:-]{1,128}$ |
manifest | object | yes |
list
POST /api/compute/releases/list
Returns every registered release, highest sequence first.
The list is not filtered by tenant: releases belong to the platform.
- Kind: read
- Authorization:
compute:fleet:admin@compute-fleet - Module:
rollout - Phase: v0.4 (registered)
Input
| Field | Type | Required | Constraints |
|---|---|---|---|
tenantId | string | yes | at most 128 characters; matches ^[A-Za-z0-9._:-]{1,128}$ |
Better Compute is created by Sean Filimon
Last updated
quotas
A quota caps how much of one resource a tenant may hold in one pool at the same time, as a `max` and a `used` counter per tenant, pool and resource. A missing row grants 0; `pools.create` and `pools.offer` create the rows, and admissions charge them with `QUOTA_EXCEEDED` when a request does not fit. See [Quotas and usage](/docs/guides/capacity/quotas-and-usage).
reservations
A reservation is a tenant's claim on devices of one pool for a time window. `create` first writes the request as a draft, Better IAM decides once on that draft with the request as attributes, and only an allowed draft is charged against quota and placed. A reservation holds its quota charge until it reaches a terminal state, and the `capacity.reservations` reconciler drives it through `placed`, `binding` and `active` to `released`. See [Reservations](/docs/guides/capacity/reservations).