diff --git a/suse-autoyast-deploy-phase1.md b/suse-autoyast-deploy-phase1.md deleted file mode 100644 index 281ef2c..0000000 --- a/suse-autoyast-deploy-phase1.md +++ /dev/null @@ -1,322 +0,0 @@ -# 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