Live Remote Validation¶
pk3s now has a small live validation layer focused on the public remote workflow.
The goal is narrow: prove that the CLI can resolve published remote bundles, accept either a remote profile URL or a generated local .env, and drive the corresponding productive-k3s-infra release end to end.
Entry points¶
Use the aggregate targets:
Or run a single validator:
make -C tests test-live-remote SCENARIOS=multipass
make -C tests test-live-remote SCENARIOS=onprem-basic
make -C tests test-live-export
Covered scenarios¶
multipass¶
The validator:
- forces
PRODUCTIVE_K3S_SOURCE=remote - validates the published Multipass profile URL through
pk3s profile validate - runs
pk3s plan - runs
pk3s apply - runs
pk3s status - runs
pk3s destroy
This is the closest CLI-level proof that the remote published Infra bundle is usable for the built-in Multipass profile.
catalog-multipass¶
The validator:
- forces catalog-backed resolution
- validates the published Multipass profile package through
pk3s profile validate - runs
pk3s infra install - runs
pk3s infra status - runs
pk3s addon install - runs
pk3s infra destroy
This proves the catalog-backed package UX against a real local Multipass target.
stack-export-ubuntu24¶
The validator:
- downloads the published
basestack artifact - runs
pk3s stack export --tgz ... --output ... - hands the generated installer to the validated Core VM harness
- boots an Ubuntu 24.04 VM
- runs the exported
install.sh - checks that the base stack namespaces exist
This proves the public CLI path for cli -> core -> exported installer.
profile-export-multipass¶
The validator:
- downloads the published Multipass profile artifact
- writes a temporary env override with a unique cluster name
- runs
pk3s profile export --tgz ... --env-file ... --output ... - extracts the generated installer
- runs the exported
install.sh - checks the bundled
productive-k3s-infra.sh profile status --tgz ... - verifies that three Multipass instances were created
This proves the public CLI path for cli -> infra -> exported installer.
onprem-basic¶
The validator is intentionally external to the scenario:
- create two ephemeral Multipass VMs
- wait for SSH reachability
- generate a temporary
onprem-basic.env - force
PRODUCTIVE_K3S_SOURCE=remote - run
pk3s profile validate - run
pk3s plan - run
pk3s apply - run
pk3s status - run
pk3s validate - delete the ephemeral VMs
This validates the CLI path for a remote-style profile without touching the local host.
Artifacts¶
Every live invocation writes:
- one manifest per scenario under
test-artifacts/cli-live-runs/ - one log per scenario under
test-artifacts/cli-live-runs/ - one root summary under
test-artifacts/<run-id>-summary.json - one convenience copy at
test-artifacts/live-summary.json
The manifests include:
- scenario name
- pass/skip/fail result
- timestamps and duration
- expected topology
- CLI binary path
- configured Core and Infra bundle versions
Notes¶
- These validators are intentionally separate from
test-local-all. - They also require a working local
Gotoolchain because the live targets buildpk3sbefore running the validators. - They require real dependencies such as
multipass,ssh,curl,tar, andpython3. onprem-basicdoes not usepk3s destroy, because that scenario does not expose a public destroy contract. Cleanup is done by deleting the temporary VMs.- Use
make -C tests test-checkstatusto inspect recorded CLI artifacts. - Use
make -C tests test-cleanto remove local CLI test artifact state.