Changelog

The changelog lists every Hangar release, with what changed and the digests of the published artefacts. The release procedure adds one entry for each release.

Next release#

This entry lists what the next release adds. The release procedure gives the entry its version, its date and its digests.

• The patch version 5.2.10 follows 5.2.9. The key site and its menu bar app are simple to run. hangar-keysite start, stop, restart, status and help take ~/hangar-keysite/keysite.json by default, and stop is the safe stop (the stop request, which wipes the keys), never a signal. Each cell host's two API units are one unit pair (api-a with api-b, mel-api-a with mel-api-b): a pair is healthy when one of its planes is open, so the app shows a green tick with one unit idle, and the status file names each plane's pair. hangar-ops tools install also builds the app and places it in ~/Applications. The app has Restart, Help and Open at login. The help shows the build's commit and its date, and the date the help was last updated; a test fails when the help changes without its date. No code of the control plane changes.
• The patch version 5.2.9 follows 5.2.8. A new cell's host serves the web app. The cell bootstrap's config step makes the system user hangar-app, /etc/hangar-app/cell.env (the cell's app values), /usr/local/libexec/hangar/hangar-app-start and the hangar-app unit (the new reviewed files deploy/production/hangar-app-start and deploy/production/systemd/hangar-app.service), and secrets makes the cell's app-session-secret; the Director places tls/web for the cell's app name. hangar-ops deploy web puts the pinned Node (deploy/production/node-linux-x64.sha256) in each cell's bucket, and the host installs it when its own Node differs or is missing; the host checks the app under the cell's app name (app-mel.gethangar.au in Melbourne). The hangar-cell-bootstrap SSM document carries the script gzip-compressed. --commit is optional on deploy api, deploy web, build control, image build, image serve, tools install and cell bootstrap (decision 156): left out, the command fetches origin, takes origin/main, prints that commit first, and refuses while the local main holds commits origin/main lacks. No code of the control plane changes.
• The patch version 5.2.8 follows 5.2.7. The host deploy script checks a unit's health under the cell's own API name (api-mel.gethangar.au in Melbourne), the name on the cell's certificates; it was fixed at api.gethangar.au, so the first Melbourne deploy rolled back a unit that served. The cell bootstrap's config step writes the hangar-jobs unit (deploy/production/systemd/hangar-jobs.service, new) when the host has none, so the first deploy can start hangar-jobs. A rollback on a host with no jobs unit prints no systemctl message. The website archive carries no macOS extended attributes. No code of the control plane changes.
• The patch version 5.2.7 follows 5.2.6. The cell template deploy/production/cell/hangar.toml.template sets both checkout return pages on the cell's own app origin (@@APP_ORIGIN@@/credit/paid and @@APP_ORIGIN@@/credit), the origin public_origin names. The template fixed them at https://gethangar.au, so hangar-api refused the Melbourne configuration at start. A new test fills the template with the Melbourne values and runs the production rules of hangar-api on it. No code of the control plane changes.
• The patch version 5.2.6 follows 5.2.5. infra/aws/cell-mel/c15-hosts.zsh apply adds a zone of hangar-mel-nlb back with its Elastic IP address only after the load balancer's network interface in that subnet is gone. A removed zone leaves the load balancer's description before AWS ends its removal, and AWS refused the add with ValidationError ... in the process of being removed. No code of the control plane changes.
• The patch version 5.2.5 follows 5.2.4. Melbourne's API load balancer hangar-mel-nlb answers on two Elastic IP addresses, hangar-mel-nlb-az1 and hangar-mel-nlb-az3, one per zone, as Sydney's hangar-nlb does. infra/aws/cell-mel/c15-hosts.zsh allocates them and binds each zone in place: it removes the zone, then adds it back with its address, so the load balancer keeps its DNS name and its listeners. The key site dials the two fixed IPv4 addresses, and a customer's firewall can list them. No code of the control plane changes.
• The patch version 5.2.4 follows 5.2.3. hangar-ops deploy api ships the website's files and the DFAT converter with every release: it builds web.tar.gz from the commit (the browser verifier hangar_cert.wasm, the hashed files of tools/assets.py and their manifest, verify.html and tools/dfat_to_csv.py), uploads it beside the host files and passes its SHA-256 to the host's install. install checks the archive's digest and entries before it installs anything, then places /usr/local/share/hangar/web (keeping the previous folder as web.prev) and /usr/local/share/hangar/tools/dfat_to_csv.py. A new cell host had none of these files, so hangar-api would not start there, and a release's changed website files had never reached a host. The SSM document hangar-api-deploy is applied again for this release. No code of the control plane changes.
• The patch version 5.2.3 follows 5.2.2. The config step of ops/onhost/cell-bootstrap.sh makes the system user hangar, /var/lib/hangar (hangar:hangar, 0750) and /etc/hangar (root:hangar, 0750) when they are missing, as the Sydney host has them. The units run as hangar, and the host image carries none of the three, so the step stopped at chown: invalid group: root:hangar. plan lists the user. No code of the control plane changes.
• The patch version 5.2.2 follows 5.2.1. The config step of ops/onhost/cell-bootstrap.sh looks up the cell's three GPU subnets with a filter that has no comma at the end. The earlier filter ended with a comma, so the AWS CLI refused it (ParamValidation) and hangar-ops cell bootstrap melbourne stopped at config with nothing written. The test's stub aws now refuses such a filter as the AWS CLI does. No code of the control plane changes.
• The patch version 5.2.1 follows 5.2.0. The SSM document hangar-api-deploy carries ops/onhost/api-deploy.sh gzip-compressed and base64-encoded, because the script (90 KB) is larger than the 64 KiB that an SSM document holds. The host unpacks the script before it runs it, and wp7-ssm-deploy-doc.zsh verify checks the SHA-256 of the unpacked script against the repository's. No code of the control plane changes.
• What a person starts is a job. The API paths are /v1/jobs and /v1/release-jobs, with the same sub-paths, and a slot lists its jobs at /v1/slots/{id}/jobs. The fields are job_id, jobs and release_job_id, and the error codes start with job_ and release_job_, with the same meanings and HTTP statuses. hangar status lists jobs, and the web app shows them on the Jobs page. The verifier prints "job certificate" and "Job". hangar run keeps its name. The worker routes, the certificate kind release_run and the data scope run_inputs keep their names. The request key capability runs is now jobs: the migration changes every existing key, and Hangar refuses a new key with runs (key_request_invalid).
• A job certificate of the hosted service carries two new facts: key 22, the places where the job's data was processed, staged, stored and recorded, and key 23, the Region policy with its source. A verifier of version 4 refuses a certificate with these keys, so the CLI 5.0.0 and the browser verifier of 5.0.0 go out in the same window as the control plane.
• A client of version 4 that calls an address that this release renamed gets client_too_old (410). The detail names the new address and the versions to update to: the CLI 5.0.0 and the Python package gethangar 2.0.0. The API refuses the Python package 1.x with sdk_too_old (426). The CLI 5.0.0 sends Hangar-Client: cli/5.0.0 with every request. A CLI of version 4 sends no Hangar-Client header, so the API refuses its POST /v1/instant, POST /v1/sandboxes and POST /v1/slots/hold with client_update_required (426), before Hangar holds credit or charges. The detail names the CLI version to update to.
• This release is the major version 5.0.0, because the API contract changes and keeps no old name. The deploy has a planned outage: the control plane and the background jobs stop, migration 0052_job_rename.sql renames the tables and columns, and the new release starts. A client of version 4 updates to the job names.
• The minor version 5.1.0 follows 5.0.0 (D-20 WP9). The deploy has no outage. Migration 0053_block_machines.sql adds columns with defaults and rebuilds the slot exclusion and the live-session index per machine: it locks the tables block, slot and instant_session for the length of the migration, so the deploy runs when no session is live or starting. Migration 0054_serving_push.sql is additive: it adds the platform tables serving_push, serving_upload, serving_blob and platform_image_key, with no organisation column. Migration 0055_immutable_tags.sql is additive: it adds the table image_version, fills it from the existing images with a version tag, and adds the trigger that keeps each version on its digest. Every existing block has 1 machine, and every existing slot and session is on machine 0. The release adds:
• Live block adopt. hangar-ops block adopt RESERVATION [--dry-run] adopts a capacity reservation bought in AWS while the API serves (POST /v1/ops/blocks/adopt, proposal kind block_adopt, one touch). The new codes are reservation_unknown (404), reservation_not_adoptable (409) and reservation_changed (409).
• Machines of a block. A block holds 1 to 4 machines (block.instance_count). Each machine takes its own session, and the free check, the launch and the wipe work on each machine. hangar status and the start of a session show the first free machine, or the earliest time a machine is free.
• Why a session started late. GET /v1/ops/slots/{id}/start and hangar-ops check why-start SLOT show the marks of Hangar beside the CloudTrail RunInstances and TerminateInstances times, with the lost block minutes.
• Serving images belong to the platform (decisions 149 and 150). A serving image is a platform asset, as a machine image is: no organisation owns it, and TALOS Defence as a user of Hangar is an ordinary organisation. hangar-ops image serve gives a release builder a 60-minute grant to the platform repository platform/quarantine/NAME, and hangar upload --image ARCHIVE --name NAME:VERSION --grant - pushes the image with the grant. The bytes go to the platform's own store under platform/serving/ in the images bucket, sealed under data keys that the platform image key wraps. hangar-ops image promote-serve NAME@VERSION --digest sha256:... promotes the image by digest (proposal kind serve_promote, one touch; the card names no organisation). Every record of a serving image is on the platform chain. The new routes are POST /v1/ops/serving-images/push and GET /v1/ops/serving-images. The new codes are serving_push_not_found (404), serving_digest_mismatch (409) and serving_version_taken (409). Each content path of the platform's store holds one blob or one manifest, written once under the data key its row names: two finishes of one digest store it once, and a blob whose digest is a stored manifest (or the reverse) gets registry_upload_invalid (400). An upload that fails removes its parts, and the block watch removes the parts of an upload left past its end. Each cell has its own platform store and key: a Trainium2 serving image is pushed to the Melbourne cell. The directory images/trn2-serve is frozen (decision 70).
• The platform's store and each organisation's registry are separate namespaces. A job, image row, pull, tag, package version, sandbox session, release and public fetch of an organisation resolve only in the registry of that organisation. A platform serving name or digest reserves nothing there: an organisation pushes, tags, pulls and runs its own trn2-serve as before, and a job that names an image the organisation does not hold gets image_unresolved (422).
• Sign-up compares the stored ABN. The check for a number already in use compares the ABN that each organisation stores, so an ACN sign-up of a company whose ABN a live organisation holds is held as duplicate_identifier.
• Migration 0055 locks image first (SHARE ROW EXCLUSIVE), so no write falls between the backfill and the version trigger.
• The wipe gate across a block. Migration 0056_wipe_gate.sql is additive: it adds the table instance_wipe_gate. On a block of more than one machine, the capacity check reads the instances of the reservation by id (DescribeInstances filtered on the capacity reservation). An instance that is ending and that AWS still lists (shutting down) holds no launch on another machine, so each end on a Trainium2 block no longer stops every launch for more than ten minutes. An instance that has no wipe record and that AWS does not list holds every launch on the block, also when an instance that Hangar does not know is in the reservation. A launch writes its gate row as pending in the transaction that adds the instance, releases the capacity lock and answers. A task of its own then settles the row: it reads the list again while AWS lists the new instance as pending, until AWS lists it as running or gone, with a deadline of 600 seconds from the launch ([blocks] gate_settle_ms), below the worker's manifest wait of 900 seconds. In the last read, the gate counts an earlier instance with no wipe record only when AWS lists it as running. The gate holds every other one (listed as pending, shutting down or stopping, not listed, or wiped in between) and waits for its wipe record. When the new instance does not run before the deadline, the gate holds every one and raises the alert block_launch_failed (wipe_gate_never_running). The row records the measured time from the launch to running (running_after_ms), and why-start shows it. While the row is pending, the manifest waits. The block watch settles a row that is still pending after [blocks] gate_sweep_seconds (the settle's deadline plus two watch intervals; 720 seconds in production) from one read of the reservation by the same rule, and raises block_launch_failed (wipe_gate_swept) when the row holds an instance with no wipe record. The control plane refuses a configuration where either gate setting is 0, the settle's deadline reaches the worker's manifest wait, or the sweep age is below the settle's deadline plus two watch intervals. A mark that fails after the launch commits is logged and does not fail the launch. POST /v1/ops/slots/{id}/launch and the delivery event start the launch as a task of its own, so a caller that goes away does not stop a launch. A launch that ends early leaves no advisory lock on a pooled connection: the connection closes and the lock ends with it. A reboot in place is read by its machine. The gate's answer is written when the manifest first passes it, and the mounted movement names the same wipe record. The block watch starts a booked wipe again 25 minutes after its terminate request, or when AWS has ended the instance and no longer counts it. POST /v1/ops/slots/{id}/launch passes every launch check of a start and answers pool_busy while the block's capacity is not clear. GET /v1/ops/slots/{id}/start and hangar-ops check why-start list every instance of the block that is ending with no wipe record, and show the wipe gate row of each instance: pending, counted and held, and what settled it. The optional setting [blocks] capacity_wait_ms sets how long a start waits for the block's capacity lock (30 000 ms when absent).
• Version tags never move. A version tag is three numbers separated by dots, such as 1.2.0. Once a version names a digest, it names that digest for good, in every organisation (decision 71). A push completion or a tag that gives a version another digest gets the new code tag_immutable (409), also after the image was removed. Push or tag the image as the next version. The same digest again succeeds and leaves the image as it is. latest and the other tags move as before.
• The minor version 5.2.0 follows 5.1.0 (D-20 Section 13.19, WP10a and WP10b). It adds capabilities and breaks no contract. The deploy has no outage. Migrations 0057_upload_completion.sql, 0058_platform_finding.sql, 0059_ops_read_token.sql and 0060_release_image_snapshots.sql are additive, so the 5.1.0 release keeps serving beside them during the switch. The SSM document hangar-api-deploy is applied again in both Regions before the deploy: its host script gains the steps config, web and web-rollback, and the switch checks the digests of the approved deploy. The Python package gethangar is 2.1.0: it waits for an upload to complete. hangar-ops is the one operator tool: help for every command, six classes of authority, the queue and do, the deploy group, the operations screen, and the commands that replace the setup guide's blocks. The entries below give each part.
• Upload completion (D-20 Section 13.19, decisions 75 and 76). The minor version 5.2.0 adds a capability and breaks no contract. The deploy has no outage. Migration 0057_upload_completion.sql is additive: it adds nullable columns and hashed_through (default -1) to upload, stored_at to upload_chunk (filled for the existing rows), a wider check on upload.status with the state completing, and the index upload_completion_due. The release adds:
• A chunk size for each upload. A file that needs more than 9,000 chunks of limits.chunk_bytes gets larger chunks, in whole MiB, so the file stays under the S3 limit of 10,000 parts: 43 MiB for 400 GB, 59 MiB for 512 GiB. A file above 70.3 GiB was refused at the last step before. The body limit of the chunk upload alone follows the largest chunk that limits.max_object_bytes gives; every other request keeps the limit of 8 MiB and 64 KiB. The start refuses a max_object_bytes that needs a part above 5 GiB.
• The compose in parallel. Hangar copies up to 32 parts at once inside S3, and removes the staging chunks with one call for each 1,000 keys.
• Completion as a job. POST /v1/uploads/{id}/complete queues the check and the store. With Prefer: respond-async it answers 202 at once; the new route GET /v1/uploads/{id} gives the state, the chunks checked, and the object or the error. Without the header the request is held up to limits.completion_hold_secs (300 s) and answers 201, or idempotency_in_progress: the CLI 5.x asks again with the same key, and the final answer for that key is the 201 object. A job holds a lease of 60 s on each upload, so a stopped process's upload is finished by another. The movement record names the person or the key that completed the upload.
• The digest as the chunks arrive. Each chunk adds to the whole-file digest when the chunk arrives in order, so the completion has normally nothing left to read.
• A new error code: upload_completion_failed (503, retryable). The chunks stay, and a new completion with a new key stores the file. upload_incomplete no longer keeps its idempotency key, so the same key completes after the missing chunks are sent.
• The Python package gethangar 2.1.0 waits for the completion. GET /v1/versions shows 2.1.0 as current; the oldest served stays 2.0.0.
• A rollback to 5.1.0 is a point-in-time restore of the database to a time before the migration, because 5.1.0 does not start on a database that holds 0057_upload_completion.sql. Follow docs/runbooks/upload_completion_rollback.md. The Director raises limits.max_object_bytes to 512 GiB only after the completion tests pass (decision 76).
• The operator queue (D-20 WP10b B1 and B2). The minor version 5.2.0 adds the routes and breaks no contract. Migration 0058_platform_finding.sql is additive: it adds the table platform_finding. During the two-unit minute, 5.1.0 still opens one flag for each GuardDuty event; the old flags stay open until a proposal closes them. The release adds:
• One item for each GuardDuty finding. Hangar keeps one platform_finding row for each finding id, with the update count and the highest severity. A finding on the instance of a customer's slot opens one flag on that organisation, and the decision of the flag closes the finding. A finding with no organisation is one item of the incidents queue, which queue_close closes.
• An advisory closes with its pairs. advisory_close clears the advisory_received alert and closes the rebuild item in the same transaction. The alert has the clock of its advisory (48 hours or 14 days). The advisory feeds match whole package names. GET /v1/ops/advisories lists the open advisories with their count; ?status=closed and ?status=all list the others.
• Queue items carry their facts. Each item of GET /v1/ops/queues has ref (the last 8 hex characters of its id), organisation, org_name, subject, subject_kind, job, evidence, detail and group. GET /v1/ops/items/{ref} resolves a ref or an id to one open item or pending proposal. GET /v1/ops/organisations?q= lists organisations by a part of the legal name or the end of the id. GET /v1/ops/get/{kind}/{id} also reads a flag, an alert, an organisation and a platform finding.
• Expired is a state. A proposal has state, which is expired for a pending proposal past its validity. GET /v1/ops/proposals lists only the proposals that can still be approved; ?status=expired lists the expired ones. A vote or a touch on an expired proposal gets proposal_expired (409). An expired proposal no longer counts in the day's one-person sum of money.
• Subjects are checked when the proposal is made. A flag, an automatic credit, a held sign-up, an incident and the item of a queue_close must exist, be open and belong to the organisation of the card. A refusal comes before any touch.
• A new error code: ops_subject_state (409), the one operator refusal for an item that is missing, closed, ambiguous or of another kind. The detail carries why, subject_kind and state; an ambiguous ref also carries candidates.
• The operator reads, the read-only token and the operator's own keys (D-20 WP10a and WP10b), on the server. The minor version 5.2.0 adds routes and one proposal kind and breaks no contract. Migration 0059_ops_read_token.sql is additive: it adds the table ops_read_token, which names the session that made each token, and the nullable column credential to operator_login and operator_session, which names the hardware key of the sign-in. Migration 0060_release_image_snapshots.sql is additive: it adds the nullable column snapshot_ids to release_image. The release adds:
• Five operator reads. GET /v1/ops/pools, GET /v1/ops/operators, GET /v1/ops/organisations/{id}/objects (newest first, at most 200), GET /v1/ops/blocks/{id}/slots and GET /v1/ops/sanctions answer this cell's rows with ids, states, counts and times, and name the cell. An unknown organisation or block is ops_subject_state with the state not_found.
• A read-only token for agents. POST /v1/ops/read-tokens makes a token hga_ of the class read, with an expiry of at most 30 days and 1 to 16 source ranges. GET /v1/ops/read-tokens lists the tokens without their values, and POST /v1/ops/read-tokens/{id}/revoke ends one. The session that makes a token must name a live hardware key; a session made before 5.2.0 names none and is refused with session_ended. hangar-ops token create|list|revoke runs these routes: create and revoke are the Director's own steps, refused in an agent shell, and create prints the value once, single-quoted, in the line export HANGAR_READ_TOKEN='...', the only line on standard output, and refuses a /0 range. The token reaches only the operator GET routes of its allow list, which answer counts and kinds: the new GET /v1/ops/read/summary, /v1/ops/version, /v1/ops/deploys, /v1/ops/platform, /v1/ops/platform/{version}, /v1/ops/keys/status and /v1/ops/metrics. Hangar refuses the token with role_too_low (403) on every other route and method, before the handler and the idempotency key. Hangar keeps the SHA-384 of the token only.
• Revoke a hardware key. The proposal kind credential_revoke (role security, one approver; decision D1-R) revokes one of the proposer's own hardware keys, for hangar-ops key revoke. A touch of another live key of the same operator approves it: the touch page offers the other keys, and Hangar refuses a touch by the key being revoked with hardware_key_required. Hangar keeps the last live key: the proposal and the execution each refuse its revocation with ops_subject_state and the state last_live_key. Every later sign-in and touch with a revoked key is refused. The revocation also ends, in the same transaction, every session signed in with that key and every read token those sessions made. An operator with several live hardware keys opens a touch with any of them.
• The evidence keys of a job. GET /v1/ops/jobs/{id}/evidence, for hangar-ops evidence run, gives the job's state, times and image digest, its slot and window, and each machine with its instance id, zone and times. The answer holds ids, digests and times only: no command, environment name, image reference, organisation or output.
• The image a block launches. POST /v1/ops/releases/{id}/images takes the snapshot ids of the AMI (snapshot_ids, optional). hangar-ops release register-image and hangar-ops image release send them: they read the ids with aws ec2 describe-images and the build account's reader in the image's Region, and register-image --snapshot-ids gives them instead. GET /v1/ops/reservations/{reservation}/image, the source of hangar-ops fsr on, names for one block the promoted image release of its profile, its AMI in the block's Region and the AMI's snapshot ids.
• The deploy commands reach every cell (D-20 WP10a, decision 110, in 5.2.0). hangar-ops deploy out --cells melbourne,sydney deploys the control plane to each cell as its own recorded step (api:melbourne, then api:sydney), each with its own Deploy proposal and touch, and deploy resume deploys only the cells not done. hangar-ops deploy web --cells melbourne,sydney builds the web app once and installs it on each cell's API host, from that cell's deploy bucket and through that cell's SSM document. A refusal in one cell stops the cells after it and names each cell's state; no cell is rolled back by itself. deploy rollback --web --cells takes the web app back on the named cells. Without --cells, each command acts on Sydney. hangar-ops tools install checks each tool against the SHA-384 manifest of its own build and says that the digests come from that build.
• The advisory check reads the web app's npm lock (D-20 WP10, decision 132, in 5.2.0). The check stage sca queries OSV.dev for every package in app/package-lock.json, dev dependencies included, as it does for every crate in Cargo.lock. An advisory passes only with a VEX statement in deps/vex.toml for its exact pkg:npm/ component.
• A GPU session takes nothing from credit until its job starts. A session whose machine fails before the job starts, at the attestation, the reset, the staging or the creation of the job's container, costs A$0.00. The live view of hangar run says that the job never started.
• A GPU session whose machine does not report ends as Failed, with the reason in one sentence. hangar status, hangar logs and the live view of hangar run show the reason. Hangar ends the machine, frees the slot at once and charges nothing when no job started. The worker reports a failed step with its name and the error text, and sends its step once a minute. hangar stop ends a session at once when no job has started.
• Packages and releases: A vendor describes its application in hangar_package.json and signs each release with its own release key. TALOS Defence accepts a release after its checks and a self-test whose signed return verifies. The release has channels, pins, widening approval and revocation, with the signed revocation list. At every job, Hangar measures a widening against the baseline release of the tenant. The signed return carries the baseline, so hangar verify recomputes the widening. A revocation stops queued and running work of the release, and stops new jobs.
• Jobs of a release on the CPU pool hosted-cpu-syd, for a tenant. Each job stays inside an envelope that TALOS Warrant compiles before the job. Events are newline-delimited JSON. The signed return shows the release, the envelope, the pool and every attempt. hangar verify checks the release in a return.
• Tenants, request keys signed with Hangar-Signature, the usage report for each tenant, and the Python package gethangar 2.0.0, which uses the standard library only.
• A request key with jobs can start, follow and stop a GPU now (hangar run --gpu, POST /v1/instant, client.instant in the Python package). The key can also read the jobs, bookings, logs, outputs and certificates of the organisation. The key spends credit only through the jobs it starts, inside the limits of the organisation. The key never books, tops up or approves. Jobs and sessions record started_by.
• Pools as an object, with registration, licence, local records contract and offline bundles for the customer-controlled form. Hangar offers the customer-controlled form from 2027.
• The error catalogue marks each code retryable or not.
• Hangar checks every image in the request that pushes or registers the image. The checks cover the platform (linux/amd64 for GPU jobs, linux/arm64 for the CPU pool), the media types, the size that a slot allows and the CUDA version. For a multi-platform index, Hangar checks each of its linux/amd64 and linux/arm64 images, and preflight_detail.platforms holds one result for each. preflight keeps its meaning: the result for the image that a GPU job takes. A GPU job needs its linux/amd64 image to pass. A sandbox session needs its linux/arm64 image to pass. GET /v1/images shows the result with the platform, the CUDA version and the entrypoint. When the image fails, preflight_error shows the reason and the next step. A tag takes the result of the digest that the tag names. The new codes are preflight_media_type, preflight_image_missing and preflight_unreadable. hangar upload --image lists each platform that the image passed for, with the pool that runs the platform.
• A sandbox session checks each image from your registry when the session opens. The image must pass for linux/arm64 and fit the 8 GiB of the CPU pool. Hangar refuses the session with the code of the failed check, such as preflight_too_large or preflight_architecture, before an instance starts. The worker checks the platform and the size again when it stages the image. For a pushed image, the worker checks before it fetches a layer.
• The worker of a session renews the presigned URLs of its images when they near the end of their 15 minutes. The worker renews them once more after the store refuses a URL. Staging therefore runs for as long as the bytes take. An upload in parts renews its storage credential between parts, so one large output outlasts one credential.
• Sign-up checks the ABN on the Australian Business Register. Hangar refuses a cancelled ABN with abn_cancelled and an unknown ABN with abn_not_found. A person checks a name that is not like the names in the register, and a register that does not answer. The organisation records the entity name and the GST registration from the register. A tax invoice of A$1,000 or more uses the GST registration.
• The reference package hangar_patch_agent 1.0.0 in examples/patch-agent. The envelope of the package requests no destination.