ceos/suse-autoyast-workflows
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
suse-autoyast-workflows/suse-autoyast-deploy-phase1.md

11 KiB
Raw Permalink Blame History

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:
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:
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:
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:
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:
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:
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:
virsh domblklist CLIENT-PROFILE-NAME --details
  • Checkpoint immediately after verification passes, before any deviation is applied:
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:
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 <name> vs <n> 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