Compute

Preview — pending review

This reference is generated from the platform API contract and is still under review. Operations, fields, and descriptions can change before publication.

Live per-flavor placement availability in a region, for the size picker

GET
/scopes/{scopeId}/compute/flavors/availability

Answers, for every published flavor, whether AT LEAST ONE host THE FLAVOR MAY LEGALLY LAND ON can place it RIGHT NOW — the same Placement inventory publiccloud.compute.precheck.assert_flavor_schedulable still checks authoritatively at create time. Lets the size picker grey out what cannot be built instead of letting the customer choose it and collect the failure at create time. The answer is a SNAPSHOT and races other tenants' creates by nature; it narrows the failure window, it does not close it — available: true is never a reservation. TWO FILTERS, BOTH NECESSARY: a flavor may carry placement constraints that pin it to a subset of the region's hosts, and the verdict is computed over THAT subset only. A machine with room the flavor may never run on does not make it available, and a host it may use but that is full does not make it unavailable on the region's behalf. A flavor with no constraints is evaluated over the whole region, exactly as before. WHAT THIS DELIBERATELY DOES NOT RETURN: no host capacity, no totals, no free counts, no host list, no aggregate name and no host count — a customer must not be able to read the cloud's remaining headroom, or its placement topology, off a size picker. Each flavor gets a boolean and at most one reason from a small, OPEN-ended vocabulary the portal translates and falls back to a generic sentence for an unrecognized value (never a closed enum, so a new reason string cannot fail parsing and silently drop the filter for every flavor). GPU IS AN UPPER BOUND, NOT A GUARANTEE. For a flavor that demands passthrough GPU devices, only the vCPU/RAM/disk half of the question is answerable here: device counts are enforced by Nova against its own pci_devices table, and no Placement provider in this cloud reports GPU inventory of any kind. Such a flavor therefore comes back available: true with reason: gpu_supply_unknown, and a create for it can pass every check and still fail to schedule. The endpoint reports that as unknown rather than inventing a count in either direction. Validation: scopeId must resolve to an accessible scope else 403 FORBIDDEN; region, when given, must be a region the active subscription can use else 422 VALIDATION_FAILED. Async & state: Synchronous read; no state change. Errors: 401 unauthenticated; 403 caller lacks a read-capable role (owner|admin| contributor|reader) on the scope; 404 unknown scopeId; 422 unknown/invalid region; 503 when the Placement API for the region cannot be read (availability is UNKNOWN, not "all unavailable"); 500 read-model failure. Idempotency/Concurrency: Safe, cacheable; no idempotency key required.

Authorization

bearerToken
headerAuthorizationBearer <token>

An API token (pc_live_…) or a service-account key (sak_live_…), created in Identity & Access Management and sent as Authorization: Bearer <token>. Requests are rate limited per credential and per tenant: every response carries X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset, and a refused request gets 429 RATE_LIMITED with Retry-After.

Path Parameters

scopeId*string

Opaque ownership+authorization scope resolving to tenant + subscription + project.

Query Parameters

region?string

Restrict the result set to a single region.

Match^[a-z][a-z0-9-]{1,39}$

Response Body

Per-flavor placement verdicts for the resolved region.

application/json
  1. response

Per-flavor placement verdicts for one region, from GET .../compute/flavors/availability.

region*string
flavors*array<>
curl -X GET "https://example.com/scopes/string/compute/flavors/availability"
{  "region": "string",  "flavors": [    {      "flavorId": "string",      "available": true,      "reason": "string"    }  ]}