feat(deploy): list Trinity on Vultr as an imageless marketplace app (#2282)

[obasilakis]

Vultr's Marketplace takes an imageless app: a Vendor Data script Vultr runs once, as root, through cloud-init on a clean Ubuntu 24.04. No snapshot, so nothing to rebuild or resubmit per release.

What this adds

• scripts/deploy/vultr-vendor-data.sh (new) — the file pasted into the vendor portal. Resolves the latest release, clones it, exports TRINITY_IMAGE_TAG, sets ADMIN_PASSWORD_SOURCE=browser, installs a login banner, writes /etc/trinity/{ready,firstboot-failed} markers, then calls start.sh --provision --cloud vultr --provenance vultr-marketplace --hosted --unattended.
• scripts/deploy/vultr-marketplace.md (new) — App Instructions text, listing copy, runbook.
• start.sh — a vultr arm on provision_metadata_ip, vultr accepted by the cloud guard, and provision_apt() putting -o DPkg::Lock::Timeout=600 on every apt call in the machine phase.
• Tests — test_2282_vultr_vendor_data.py (20), and test_2380_provision_single_source.py extended to scan the new script as a fourth caller.
• Docs — PROV-017, amended PROV-011/012, and two feature flows.

Two decisions worth reviewing

Unpinned, not pinned. The script resolves releases/latest at boot rather than carrying a version literal. The copy that actually runs lives in Vultr's portal, so a repo literal is a pin nothing can enforce, and a VERSION test would guard the wrong copy while forcing an RC tag into it mid-cycle. releases/latest excludes pre-releases. A failed resolve aborts rather than falling back — a successful install of the wrong release is invisible. This deviates from AC #5, which asked for a pinned tag bumped per release; recorded on the issue.

No admin password, no app variables. trinity-enterprise#580 put marketplace installs on the browser admin claim and names Vultr. So ADMIN_PASSWORD_SOURCE=browser, nothing generated, and no password enters Vultr's metadata service — which serves app variables to every host process for the machine's life. This overrides AC #2 as written; also recorded on the issue. Vultr does support auto-generated password variables, so reinstating it later is a few lines.

The metadata read uses the plain-text path rather than /v1.json because it doubles as the "am I on a cloud VM" guard and runs before any package is installed, so it may depend on nothing but curl.

Live test

Instance vc2-4c-8gb (4 vCPU / 8 GB), Ubuntu 24.04, Frankfurt, script delivered as cloud-init user data; destroyed afterwards.

• First boot start → serving: 2m20s on the final run (3m43s on an earlier one).
• /v1/interfaces/0/ipv4/address returns the public IPv4; network-type reads public; a stock instance has one interface.
• HTTPS 200 on the bare IP, chain verifies, Let's Encrypt short-lived certificate; http:// 308s to it.
• .env: TRINITY_INSTALL_SOURCE=vultr-marketplace, tag persisted, ADMIN_PASSWORD empty, ADMIN_PASSWORD_SOURCE=browser.
• 7 containers healthy; browser admin claim worked end to end; Settings reports Vultr Marketplace.
• Four agents seeded — the acme trio plus Cornelius — and an empty operator queue.
• DOCKER-USER → TRINITY-FW present with the 169.254.0.0/16 DROP: the host reads the metadata service, a container on trinity-agent-network times out.
• Banner correct in all three states (installing / ready-unclaimed / ready-claimed); the EXIT trap wrote the failure marker on a failed run.

Not verified

• Creating an agent on a box with no model credential (not Vultr-specific).
• A VPC-attached instance — whether interface 0 stays the public one.
• IPv6-only plans; the endpoint returns nothing, and the listing states IPv4 is required.

Sequencing

The listing cannot be published until a release contains this change. The script resolves releases/latest and clones that tag, so until a release carries --cloud vultr, a marketplace boot fails with unsupported --cloud 'vultr'. The remaining ACs — vendor application, Vultr's review, the README badge — are vendor-portal work, so this closes nothing.

Dev gained AWS provisioning while this was in flight; the merge keeps both arms, and the cloud guard now reads digitalocean|vultr|aws.

Refs #2282

🤖 Generated with Claude Code

[vybe]

merge-train: pushed two commits to feature/2282-vultr-imageless so this rides today's train.

• 3adbbd17a: merged origin/dev (clean).

• 5a85599c8: updated the two pins in tests/unit/test_3004_aws_provision.py (test_the_cloud_allowlist_accepts_aws, the one regression diff failure) to the allowlist this PR introduces:

  • digitalocean\|aws\) ;; → digitalocean\|vultr\|aws\) ;;
  • "supported: digitalocean, aws" → "supported: digitalocean, vultr, aws"

  Locally, test_3004, test_2282 and test_2380_provision_single_source give 73 passed and 5 skipped. The skips need util-linux flock.

Non-blocking findings from validation, for a follow-up:

• scripts/deploy/vultr-vendor-data.sh:67-69: the retry hint runs a bare start.sh, so a manual retry after an apt-phase failure loses ADMIN_PASSWORD_SOURCE=browser and the resolved tag. It also never clears firstboot-failed or writes ready, so the banner keeps saying the first boot failed.
• Doc nits: the script header says ~10 min and PROV-017 says ~4. hosted-install.md lists <digitalocean|vultr> without aws.
• Coverage: the vultr metadata-IP read and provision_apt are only pinned as source text. test_3004's _run harness could execute provision_metadata_ip with PROVISION_CLOUD=vultr and a stubbed curl.

[vybe]

merge-train: batch validated on train/20261005-1214 (#3228, all gates green)