tritonadm image upload
tritonadm image upload puts a System image's content in the cluster's image object
store and sets its source_url, so compute nodes fetch it themselves. This page also
covers image add and image set-owner, which come before an upload.
Execution context
Every command is an HTTP call against tritond, from any host with a configured
tritonadm. image add, image upload, and image set-owner --global or --system
need root rights in the control plane. <IMAGE> is a name, name@version, UUID, or UUID
prefix.
Synopsis
tritonadm image add --name <NAME> --os <OS> --version <VERSION> --size-bytes <N> --sha256 <HEX> [--description <TEXT>] [--source-url <URL>] [--id <UUID>]
tritonadm image set-owner <IMAGE> (--global | --system | --silo <REF> | --tenant <REF>) [-n] [-y] [--keep-going]
tritonadm image upload <IMAGE> --file <FILE> [-n] [-y] [--keep-going]
tritonadm image add
Registers an image record. Leave out --source-url when the content will come from
image upload.
| Option | Description |
|---|---|
--name <NAME> | Image name. |
--os <OS> | Operating system, for example linux. |
--version <VERSION> | Version stamp. |
--size-bytes <N> | Size of the image file, in bytes. |
--sha256 <HEX> | SHA-256 of the image file. |
--description <TEXT> | Description. |
--source-url <URL> | Where nodes fetch the content. |
--id <UUID> | Image UUID. The server makes one when omitted. |
tritonadm image set-owner
Sets who owns an image. Give exactly one owner flag. Asks for confirmation.
| Option | Description |
|---|---|
--global | Any tenant can use the image. Root only. |
--system | Operator infrastructure that no tenant can list or boot, such as sandbox images, SSH relays, and NAT gateways. Root only. |
--silo <REF> | Owned by one silo. Root rights are not required. |
--tenant <REF> | Owned by one tenant. Root rights are not required. |
tritonadm image upload
Uploads a System image's content. <FILE> is the image's gzipped zfs send stream.
| Option | Description |
|---|---|
--file <FILE> | Image file to upload. Required. |
Before it sends anything, the command refuses when the image already has a
source_url, and computes the file's size and SHA-256. It refuses on a mismatch with
the record. It then asks the server for an upload URL that is valid for about one
hour, sends the file, and commits the upload. The commit checks that the object exists
with the image's size. A commit for an image that already carries this upload's
source_url succeeds again without change. On success it prints:
image <IMAGE_UUID> source_url <URL>
| Server answer | Cause |
|---|---|
404 | The caller is not root, or the image is not a System image. |
409 Conflict at the upload request | The image already has a source_url. |
409 Conflict at the commit | The image has a different source_url, no object was uploaded, the object's size differs from the image's size, the object store answered a non-success status, or it reported no size. |
Example: a sandbox image of your own
On an operator workstation with a configured tritonadm:
tritonadm image add --id <IMAGE_UUID> --name <NAME> --version <STAMP> --os linux \
--sha256 <SHA256> --size-bytes <BYTES>
tritonadm image set-owner <IMAGE_UUID> --system -y
tritonadm image upload <IMAGE_UUID> --file <IMAGE_FILE>.zfs.gz -y
tritonadm config set sandbox.rootfs_image <IMAGE_UUID>@<STAMP> --hold
Drain the pool before you change a sandbox image pin. See Upgrade sandbox components.