GloriousFlywheel Honey RustFS State Proof 2026-04-20

Snapshot date: 2026-04-20

Historical owner issue: #276

Purpose

Turn the backend-authority question from “is there actually a live environment-owned S3-compatible candidate on honey?” into a proven runtime fact.

This note is narrower than the full backend-family cutover:

• it proves the live S3-compatible candidate exists
• it proves a local operator can reach it through bounded port-forward
• it does not claim the active OpenTofu stacks have already switched from backend "http" to backend "s3"

Live Runtime Proof

Direct validation on 2026-04-20 showed:

• attic-rustfs-openebs is running in nix-cache
• that pod is placed on bumble
• attic-rustfs-openebs, attic-rustfs, attic-rustfs-openebs-hl, and attic-rustfs-hl all resolve to the same durable endpoint
• secret attic-rustfs-credentials exists in nix-cache
• a bounded local kubectl port-forward to svc/attic-rustfs-openebs succeeded
• signed aws s3api list-buckets against that forwarded endpoint succeeded

Observed buckets:

• attic
• bazel-cache
• pg-backup
• tofu-state

Meaning:

• the environment-owned S3-compatible state candidate is not hypothetical
• the durable S3 surface is the RustFS deployment on bumble, not the older non-OpenEBS compatibility alias names
• the local operator path can already prove and inspect that authority without any public exposure

State Bucket Shape

Signed listing of tofu-state returned these live objects:

• arc-runners/terraform.tfstate
• attic/terraform.tfstate
• blahaj/tinyland-dev-production/terraform.tfstate
• tinyland-infra/gitlab-runners/terraform.tfstate
• tinyland-infra/runner-dashboard/terraform.tfstate

Meaning:

• there is already live OpenTofu state in the environment-owned RustFS bucket
• the actual migration question is now key mapping and backend-family cutover, not whether the bucket exists at all
• attic and arc-runners use short keys today
• gitlab-runners and runner-dashboard currently live under tinyland-infra/
• adjacent local-cluster state is also present in the same bucket

Repo Implication

As of this proof:

• the repo is still truthful that active stack code initializes through backend "http"
• the repo is no longer truthful if it implies a live RustFS-backed tofu-state lane is still unproven

At the time of this proof, the remaining backend-authority work under #276 was:

1. choose and codify the canonical per-stack key mapping
2. decide the local operator access contract for that S3 authority
3. switch active stacks from backend "http" to backend "s3"
4. update root init helpers and docs to make that new path primary

Follow-on note:

• the repo should now treat the discovered ENV=dev keys as the current baseline migration-prep contract
• S3 backend helpers should stop defaulting to <stack>-<env>.tfstate for the proven honey baseline

Non-Claim

This proof does not say:

• that the current local operator path should already point active stacks at S3
• that CI and local paths have converged on one final S3 backend config yet
• that the current tofu-state key layout is already the intended final contract

It only says the durable environment-owned S3-compatible candidate is real and readable now.