From 9014969e79b4c3d506fd485b9e693c7e7f738d22 Mon Sep 17 00:00:00 2001 From: "John A. Hoeven" Date: Sun, 26 Jul 2026 02:08:23 +0200 Subject: [PATCH] Add checkboxes to procedural sections --- suse-autoyast-deploy-phase1.md | 322 +++++++++++++++++++++++++++++++++ 1 file changed, 322 insertions(+) create mode 100644 suse-autoyast-deploy-phase1.md diff --git a/suse-autoyast-deploy-phase1.md b/suse-autoyast-deploy-phase1.md new file mode 100644 index 0000000..281ef2c --- /dev/null +++ b/suse-autoyast-deploy-phase1.md @@ -0,0 +1,322 @@ +# suse-autoyast-deploy-phase1.md + +REFER TO ALL RELEVANT OFFICIAL SOFTWARE MANUALS + +Orchestrator workflow for the VM-based test cycle: derive a VM spec, +build the VM, run an AutoYaST deploy against it, verify the result. +Phase 1 of the initial deploy workflow — see Section: Relationship to +bare-metal deployment. Calls into separate documents for input and +subprocess steps, same pattern as a bash orchestrator calling libraries +and subscripts. + +--- + +## SECTION: Scope + + +Assumes `tinkerpad13-tooling-workflow-proposed.md` is already applied. +Assumes `opensuse-deploy-workflow-proposed.md` for version selection, +media policy, and sudo/targetpw background. + +| Referenced document | Called between | +|---|---| +| `device-profile.md` | Start of workflow | +| `autoyast-crafting-workflow.md` | VM creation and install pass | +| `autoyast-error-debugging-workflow.md` | Install pass and recording | +| `suse-deploy-post-install-testing-workflow.md` | Install pass and recording | + +None of these four are written yet. This workflow holds the sequence +and handoff points; each can be authored independently without changing +this document. + +[NOTE] Deployment planning — confirming a client's proposed use cases +are actually achievable on the hardware/spec being deployed, and making +pre-deployment recommendations — is a separate service, not part of +this workflow. This workflow tests whether a base install completes and +verifies correctly; it does not evaluate whether the deployment is the +right fit for the client's goals. + +--- + +## SECTION: Relationship to bare-metal deployment + + +This document is `suse-autoyast-deploy-phase1.md` — workbench VM testing +on tinkerpad13. Once a pass is clean, proceed to +`suse-autoyast-deploy-phase2.md` (not yet written) — same DVD image, +same verified profile, same verification checklist, executed on the +real device at the client site. + +Phase 2 doesn't re-decide anything Phase 1 already settled. It adds what +only exists on real hardware: the literal physical-presence requirement, +any hardware-specific manual checks flagged in Section: Device spec +gathering, and live deploy mods if the real device deviates from what +the VM predicted. + +The retained VM, snapshot, and clone mechanics in this document exist +because of this relationship — the retained VM is kept specifically so +Phase 2's real-world proving period has something faithful to check +itself against. + +--- + +## SECTION: Device spec gathering — via device-profile.md + + +Refer to `device-profile.md` to set VM specifications matching the +client device. Not yet designed. Required variable categories: technical +specs, connectivity state, device purpose/role. Covers base OS install +only — GPU driver stack, services, and applications are out of scope, +handled by separate provisioning later. + +- [ ] Apply CE's 25% headroom rule against tinkerpad13's total capacity, + not the VM spec in isolation. +- [ ] Confirm one VM at a time — series before parallel. + +--- + +## SECTION: VM creation — TUI, scripted + + +- [ ] Build the VM: + +```sh +virt-install \ + --name CLIENT-PROFILE-NAME \ + --memory 2048 \ + --vcpus 2 \ + --disk size=20 \ + --cdrom /path/to/downloaded.iso \ + --os-variant opensuse-leap16.0 \ + --network network=default \ + --graphics spice +``` + +Adjust `--memory`, `--vcpus`, `--disk`, `--os-variant` per +`device-profile.md` and target SUSE version. + +- [ ] Confirm the VM exists and is in the expected state: + +```sh +virsh list --all +``` + +--- + +## SECTION: Profile crafting — referenced + + +See `autoyast-crafting-workflow.md` (not yet written) for authoring or +selecting the `autoinst.xml` profile before proceeding. + +--- + +## SECTION: Install pass — GUI, attended + + +- [ ] Confirm DVD image version/date and profile version are recorded. +- [ ] Check whether `sudo-policy-wheel-auth-self` ships on the DVD or + requires a mid-install network pull (see + `opensuse-deploy-workflow-proposed.md`, Section: Sudo / targetpw + fix). +- [ ] Watch the install: + +```sh +virt-viewer CLIENT-PROFILE-NAME +``` + +--- + +## SECTION: Post-install verification — referenced + + +- [ ] Run the verification checklist from + `opensuse-deploy-workflow-proposed.md`. + +See `autoyast-error-debugging-workflow.md` (not yet written) for +diagnosing a failed check to root cause. + +--- + +## SECTION: Post-install debugging and inspection — referenced + + +See `suse-deploy-post-install-testing-workflow.md` (not yet written) for +inspection beyond pass/fail verification. + +--- + +## SECTION: Post-install — VM lifecycle, TUI + + +- [ ] Shut down or start the VM as needed: + +```sh +virsh shutdown CLIENT-PROFILE-NAME +virsh start CLIENT-PROFILE-NAME +``` + +[WARNING] Do not `undefine --remove-all-storage` on a successful pass — +see Section: VM retention below. + +--- + +## SECTION: VM retention — 90-day proving period + + +Retain the VM 90 days past physical deployment rather than deleting +immediately — the exact VM that produced a working install is the first +diagnostic step if an issue surfaces on the client's real hardware +within that window. + +- [ ] Shut down, don't undefine, on a successful pass. +- [ ] Record retention start date and client/device in the pass's + handoff record. +- [ ] Budget total retained-VM storage against tinkerpad13's capacity, + 25% headroom rule applied cumulatively, not per-VM. +- [ ] At 90 days with no traceable issues, remove: + +```sh +virsh undefine CLIENT-PROFILE-NAME --remove-all-storage +``` + +- [ ] If an issue surfaces within the window, reproduce against the + retained VM first — confirms whether it's profile-level or + hardware-specific to the physical device. + +--- + +## SECTION: Live deploy mods vs. post-deploy additions — which tool applies + + +These are two different kinds of change to the retained VM, and they +call for different tools because they sit at different distances from +this workflow's own scope: + +**Live deploy mods** — corrections discovered during the actual physical +deployment that deviate from what the tested profile/VM produced (a +hardware quirk forced a different config, a manual fix was needed +on-site). These stay *within* this workflow's scope — they're base +install corrections, the same category of thing this whole workflow +tests for. Use **snapshot**: checkpoint at base-install-verified, apply +the deviation directly to the retained VM, and the snapshot remains +available as a return point if the deviation itself turns out wrong. + +**Post-deploy additions** — a server stack, an AI stack, applications, +anything from the config/services layer this workflow explicitly +excludes (Section: Device spec gathering). These are a large leap in +scope, not a correction to the base install — a genuinely separate +workflow's work, even if it happens to start from this VM. Use +**clone**: fork the VM first, do all of that work in the fork, leave the +retained original as the untouched base-install artifact. + +Rule of thumb: if the change is something `autoyast-crafting-workflow.md` +or `autoyast-error-debugging-workflow.md` would recognize as their own +territory, it's a live deploy mod — snapshot. If it's something a future +Ansible playbook or application-layer workflow would own instead, it's a +post-deploy addition — clone. + +### Clone — post-deploy additions + +- [ ] Fork the VM before starting any config/services-layer work: + +```sh +virt-clone --original CLIENT-PROFILE-NAME --name CLIENT-PROFILE-NAME-clone --auto-clone +``` + +- [ ] Do all further exploration in the clone. The retained original + stays untouched until either its 90 days elapse or it's needed to + reproduce an actual reported issue. + +### Snapshot — live deploy mods + +- [ ] Confirm the disk is qcow2 — snapshots require it: + +```sh +virsh domblklist CLIENT-PROFILE-NAME --details +``` + +- [ ] Checkpoint immediately after verification passes, before any + deviation is applied: + +```sh +virsh snapshot-create-as \ + --domain CLIENT-PROFILE-NAME \ + --name base-install-verified \ + --description "Base install complete, verification checklist passed" \ + --disk-only \ + --atomic +``` + +- [ ] Apply the live deploy mod to the retained VM directly after the + checkpoint. +- [ ] If the mod turns out problematic later, revert: + +```sh +virsh snapshot-revert CLIENT-PROFILE-NAME base-install-verified +``` + +[WARNING] Internal snapshots require qcow2 and are not supported on VMs +using pflash-based (OVMF/UEFI) firmware. Use external snapshots +(`--diskspec ...,snapshot=external`) for those instead, or rely on clone +and 90-day retention alone. + +[NOTE] A snapshot is not a substitute for the 90-day retention policy — +it depends on the same base disk image it was taken from. It's a +finer-grained checkpoint within the retention period, not a replacement +for keeping the VM itself. + +- [ ] Limit snapshot chains to a small number — one checkpoint at + base-install-verified is normally sufficient. + +### Recording a live deploy mod + +- [ ] Record the deviation in the pass's handoff record — what changed, + why it deviated from the tested profile, and that the + snapshot/checkpoint exists. +- [ ] If a deviation depends on physical hardware the VM never modeled + and can't be fully reproduced, note that gap explicitly rather + than implying parity that doesn't exist. + +[NOTE] Same honesty standard as tinkerpad's "13b" — an unrecorded +deviation is worse than one that never happened. + +--- + +## SECTION: Test pass — recording + + +- [ ] Write a named, dated handoff record for the pass. Include: + - [ ] VM spec used (CPU, RAM, disk) + - [ ] DVD image version/date + - [ ] Profile version + - [ ] Verification checklist results + - [ ] Retention start date + - [ ] Any manual correction made outside the documented flow — named + honestly, per tinkerpad's "13b" precedent +- [ ] Clean pass → proceed to physical deployment + (`suse-autoyast-deploy-phase2.md`), same DVD image and profile, + no changes. +- [ ] Failed pass → new pass, one issue at a time, own handoff record. + +--- + +## SECTION: Known unknowns going into the first Leap/SLES test + + +- Whether `sudo-policy-wheel-auth-self` behaves identically on Leap/SLES + as on Tumbleweed +- Whether it ships on the Leap/SLES DVD or needs a mid-install network + pull +- The `` vs `` AutoYaST tag inconsistency, unresolved since + tinkerpad +- Whether firewall zone rules apply correctly post-install — never + verified on tinkerpad + +--- +**Source:** CE OS — automation testing process, developed 2026-07-25 +**Source-type:** `ce-authored` +**Licence:** John A. Hoeven with the ethical assistance of Claude AI — Public Domain (CE FFM) +**Verified-on:** unverified — proposed, pending first real Leap/SLES VM test pass +**Session:** 2026-07-25 +**Filename:** suse-autoyast-deploy-phase1.md