Stop prefetching rootfs images during node bootstrap

[artemnikitin]

Removes the rootfs image prefetch from node bootstrap and corrects architecture documentation that described the images bucket as architecture-specific.

Why bootstrap stopped prefetching

Node bootstrap prefetched images before the agent started. Two problems, both found in review:

It broke a fresh deploy under the new key layout (the original P1). With images under an <arch>/ prefix, the two providers failed in opposite directions:

• AWS — aws s3 sync preserves key structure and its * matches across /, so a node downloaded every architecture into nested directories the agent never reads: ~36 GiB of prefetch plus ~18 GiB of agent cache against a 50 GB root volume.
• GCP — gcloud storage's * does not cross /, so gs://bucket/*.ext4 matched nothing. Under set -euo pipefail that aborted the startup script before /etc/firework/agent.yaml was written, leaving a node that never enrolled.

And the prefetch was never useful. Neither cloud CLI writes Firework's write-token sidecars, so the agent re-downloaded every prefetched image moments later. Bootstrap also fetched every image for the architecture, while the agent fetches only the images assigned to that node.

So rather than teach bootstrap to select a prefix, this removes the step. The agent is the right place: assigned subset only, and it maintains the sidecars that let a restart skip unchanged objects. Both bucket variables are required by the data-plane stacks and always written into the agent config, so image sync is never disabled and removal cannot strand a node. It also retires the GCP set -e startup hazard outright instead of guarding it.

Documentation

The images bucket is no longer architecture-specific — objects live under an <arch>/ prefix and the agent resolves the prefix from its own binary's architecture.

Statements that became wrong rather than merely incomplete:

• aws/variables.tf — node_ami_architecture claimed it must match "the rootfs images in s3_images_bucket_id"
• aws/README.md — three mutually contradictory claims about whether switching to Graviton means repointing the images bucket
• packer/aws/README.md — warned about pointing a node at "an arm64 rootfs bucket"
• aws/terraform.tfvars.example — the Graviton runbook

Under one bucket, only the AMI, instance type, and architecture setting change.

Also swept iam-policies/aws/README.md, iam-policies/gcp/01-ci-images-gcs.md (including the AMD64_IMAGES_BUCKET placeholder), gcp/variables.tf, images-infra/gcp/variables.tf, and the GCP tfvars example, per AGENTS.md's instruction to keep iam-policies/ current.

Not changed

No Terraform resource or variable definitions. s3_images_bucket_id and images_bucket_name were already single-bucket variables. Node IAM is already bucket-wide — "${var.s3_images_bucket_arn}/*" (aws/iam.tf:67) and roles/storage.objectViewer (gcp/iam.tf:5-9) — so key prefixes need no policy change.

The AWS AMI row in iam-policies/aws/README.md still says ARM64: that one is genuinely architecture-specific, describing the Graviton node image build rather than rootfs uploads.

Companions

artemnikitin/firework-gitops-example#29 (publishes under <arch>/) and artemnikitin/firework#45 (agent resolves the prefix). No live environments, so merge order is unconstrained — but publish images before deploying nodes, since a fresh node has no cache to fall back on.

Testing

terraform fmt -check -recursive terraform/ clean; terraform validate passes for both data-plane stacks. Both bootstrap templates pass bash -n with Terraform interpolations stubbed. No orphaned variables left behind by the removal.