Return the rendered NoCloud seed (system meta-data + customer user-data) the next boot will see.
curl --request GET \ --url https://stratum.example.com/v1/projects/example/compute/instances/example/cloud-init/preview \ --header 'Authorization: Bearer <token>'. Single source of truth for the
cidata ISO bytes the next boot will receive AND the IMDS
endpoint will serve — assembled from the same cloudinit
package code path the boot-time builder uses, so the UI never
re-renders client-side and the server-side and IMDS surfaces
can’t drift.
The system meta-data is read-only (it’s derived from the
instance row + the linked key pair). To change a field, mutate
the underlying resource (rename the instance for hostname,
attach/detach a FIP for public-ipv4, etc.). The customer
user-data half can be modified via the PUT
.../instances/{id}/user-data endpoint (MR1).
With Accept: text/plain the response is the concatenated
NoCloud seed: <meta-data>\n---\n<user-data>\n — operator-
friendly for curl | less inspection.
Authorizations
Section titled “Authorizations”Parameters
Section titled “Parameters”Path Parameters
Section titled “Path Parameters”Responses
Section titled “Responses”Rendered NoCloud seed.
The rendered NoCloud seed an instance’s next boot
will see. metaData is the system-generated YAML Stratum
auto-injects (always non-empty: includes the instance-id at
minimum). userData is the customer-supplied bytes (empty
when the instance was launched without user-data and no
subsequent PUT supplied any). Each blob is offered in both
decoded (UTF-8 string) and base64 forms — UI renders the
decoded form; tools that need byte-perfect round-trip use
the base64 form.
object
Decoded NoCloud meta-data YAML.
Base64 of the same bytes (binary-safe form).
Decoded user-data bytes (empty when none).
Base64 of the user-data bytes (binary-safe).
Example generated
{ "metaData": "example", "metaDataBase64": "example", "userData": "example", "userDataBase64": "example"}Resource not found.
object
The findings of a rejected IAM policy document (custom and resource policies).
One finding of a rejected IAM policy document. A rejection lists every finding, so the author fixes the document in one round trip.
object
The finding, e.g. INVALID_DOCUMENT, UNKNOWN_ACTION, ACTION_NOT_APPLICABLE.
Index of the statement at fault; -1 for the document as a whole.
The offending action, where one is at fault (ACTION_NOT_APPLICABLE).
Field errors, for codes that carry them: each problem at its field
(see FieldError). Documented on the responses that set it, e.g.
approveNodeJoin’s INVALID_INPUT and JOIN_APPROVAL_REFUSED.
Absent otherwise.
One field’s problem, the stage-2 installer API’s shape.
field is the field’s path, message what is wrong with it.
object
The field’s path, e.g. links[0].interface, disks[1].confirm,
mgmt.address or role; empty for the whole request.
Structured facts about the refusal, for codes that carry them. The
shape is fixed per code and documented on the response that answers
it, e.g. IMAGE_POOL_MISMATCH (see ImagePoolMismatchDetails) and
IMAGE_IN_USE. Absent for codes that carry none.
object
Example
{ "issues": [ { "code": "ACTION_NOT_APPLICABLE", "action": "compute:CreateVpc" } ]}