This example now lives at confighub/sveltos-confighub. This copy is a frozen mirror; new work, live recordings, and issues belong in that repository.
The governed fleet chapters should not meet their cluster machinery for the first time on patch day. This rehearsal runs the delivery path they share, today, with no ConfigHub account, so when the chapters record the only untested piece is the approval boundary itself.
What it runs
One command builds a five-cluster kind fleet (one management cluster, four workload clusters registered by environment label) and installs Sveltos from the pinned manifest. The management cluster registers itself as a Sveltos-managed cluster, so one bootstrap profile can hand it every wave of fleet profiles from the registry.
Each wave publishes the complete current set of fleet profiles as one raw-YAML OCI image. Sveltos fetches that image itself and sends the profiles to every managed cluster. Nothing else carries the configuration.
- Kyverno converges on all four clusters from the fetched profile set.
- A demo application (podinfo, pinned in the source lock) rides the same rails to all four clusters with a different replica count per environment, so the per-environment fan-out is visible in the app itself.
- A values change lands on the pilot cluster alone; the other three hold their state.
- A chart version bump lands on the pilot alone with the values intact.
- Drift injected on the pilot is repaired by Sveltos.
The receipt records phase timings, so it also measures what this machine can carry before a real recording day.
The layer contract
The live remote fetch probe recorded what the fetcher accepts, and this lane holds to it. Profiles ship as a single raw-YAML layer, and the runner refuses to publish a gzipped or tar layer because the fetcher would misread it. The registry serves TLS, because the fetcher speaks HTTPS only, and the certificate authority reaches the controller in a Secret of type addons.projectsveltos.io/cluster-profile, which is the type it requires.
The boundary
No review, approval, or promotion is claimed and no ConfigHub organization is touched. The registry stands in for the ConfigHub OCI gateway, the profiles come straight from the reviewed example files instead of an approved ConfigHub revision, and the bootstrap profile is applied with kubectl as cluster setup. The receipt states these differences, its verifier refuses a receipt that claims governance, and no chapter matrix cell is ever filled by a rehearsal.
The recorded run
The committed receipt and the summary with phase timings record the first rehearsal on the reference machine. That run delivered the artifacts through a GitOps controller, which this design replaced with the direct fetch path above. The verifier recognizes the older receipt and waits for the re-record instead of checking it against the new contract.
Run it
# Deterministic self-test first: the revision ladder, the raw-YAML
# publication contract with its gzip and tar refusals, the Secret type and
# bootstrap profile the fetcher requires, and the receipt contract. Seconds.
npm run sveltos-fleet-rehearsal:self-test
# The live rehearsal. It creates its own clusters and TLS registry, records
# the receipt with timings, and cleans up. Expect twenty to forty minutes.
HELM_EXPT_ALLOW_LIVE_SVELTOS_REHEARSAL=1 npm run sveltos-fleet-rehearsal:run
# Verify the recorded receipt offline.
npm run sveltos-fleet-rehearsal:verify