claude-botandClaude Opus 5
a4b659c965
None of this is reconciled by Flux — bootstrap.sh, the vmtest Job and the Talos hcloud patches are operator tooling, applied only when a rebuild test runs. Zero effect on the live cluster from merging. New: an hcloudtest phase that provisions three cpx42 servers with private cluster/storage networks, a this-host-only firewall and one raw OSD volume per node, then hands over to the ordinary talos phase through the same four variables vmtest uses. Servers carrying the test label are adopted and rebuilt from the Talos snapshot instead of recreated — capacity, not cleanliness, is the scarce resource. Network ranges and volume sizes are derived from what the cluster itself declares (the site patch and the machine patches), never stated a second time. hcloudclean deletes everything by label. The vmtest Job clones from the GitHub mirror instead of in-cluster Gitea: a rebuild rehearsal cannot depend on the thing whose loss it rehearses, and a run died on resolving gitea.renner.uno before the first VM booted. bootstrap.sh hardening from a week of rehearsals: the OpenBao unseal loops until the StatefulSet converges instead of unsealing whichever pods existed at one instant, require_secrets takes a subset, secrets can be streamed into a waiting run, retries around talosctl bootstrap and server placement, and node waits print progress and refuse an expected count of zero. import-cluster-access.sh keeps its default AWS profile but stops overriding one the caller already chose. Known boundary, documented in site-hcloud.yaml: from master the hcloud site validates provisioning through cluster-Ready; the SAN path needs the follow-up rollout PR that renames the storage NIC by role. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>