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
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.
bearerTokenAuthorizationBearer <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.
scopeId*stringOpaque ownership+authorization scope resolving to tenant + subscription + project.
region?stringRestrict the result set to a single region.
^[a-z][a-z0-9-]{1,39}$Per-flavor placement verdicts for the resolved region.
application/json- response
Per-flavor placement verdicts for one region, from GET .../compute/flavors/availability.
region*stringflavors*array<>curl -X GET "https://example.com/scopes/string/compute/flavors/availability"{ "region": "string", "flavors": [ { "flavorId": "string", "available": true, "reason": "string" } ]}