Sales Demos Windows Image

---
name: sales-demos-windows-image
description: "Point this environment's OpenShift Virtualization at the published CIS L1 hardened Windows golden containerdisk. Required on a new environment before os_type=windows will boot — CNV ships win2k22 as an empty placeholder. Adds a DataImportCron to the HyperConverged CR and a pull secret for the private quay repository, then asks the cluster whether the DataSource really came up. Fully reversible. Runs playbooks/link_windows_image.yml. TRIGGER when: the user asks to enable or fix Windows VMs, says a Windows VM will not boot or sits forever in Provisioning, asks why win2k22 is not Ready, wants the Windows boot source populated, asks about issue #3, or wants to undo that link. SKIP: if the user wants to BUILD or publish the golden image itself — that is ericcames/image.builder.pipeline, a separate producer — or wants to provision demo VMs generally, which is sales-demos-provision."
---

# sales-demos-windows-image

## There is an AAP path now too (#318)

`Golden Image - Link Windows 2022 CIS L1` runs the same playbook from AAP. It
needs `quay_username` / `quay_password`, which now reach a job through the
"Sales Demos - Env Secrets" credential — the Windows containerdisk lives in a
PRIVATE repository, unlike RHEL 9's.

Links an environment to the published CIS L1 hardened Windows golden image.

CNV ships `win2k22` as an empty placeholder — Red Hat cannot redistribute Windows
media, so every `win*` DataSource on a fresh cluster reports `Ready=False`,
`"PVC not found"`. Without this skill, Terraform clones that empty DataSource and
the VM waits forever on a DataVolume that never imports.

This skill fills it, the same way CNV fills `rhel9`.

## This is the consumer half. It does not build anything.

| | Owns |
|---|---|
| **This skill** | Pointing a cluster at the published image |
| The producer (`ericcames/image.builder.pipeline`) | Building and publishing the containerdisk |

The contract between them is one string: `quay_windows_image` in
`inventory/group_vars/<env>/connection.yml`. All three environments currently
point at `quay.io/zigfreed/win2k22-cis-l1-golden` (private, CIS L1 hardened).
The playbook asserts the image reference is non-empty and rejects placeholder
values.

## Why a DataImportCron and not a PVC

#3 originally said "snapshot the disk to a DataSource". That is not how boot
sources are kept on a cluster, and the cluster is the proof. Measured on sandbox,
CNV 4.20.24 — `HyperConverged.status.dataImportCronTemplates` carries six
entries, fedora / centos-stream 9,10 / rhel 8,9,10, each with
`managedDataSource`, `garbageCollect: Outdated` and a registry source.

A hand-created PVC is a one-shot artifact with no refresh path. A cron makes a
fresh RHDP environment a *config* step instead of a data-movement one.

**Taking over the SSP placeholder is the designed handoff, not a fight:**

| | `win2k22` (placeholder) | `rhel9` (managed) |
|---|---|---|
| `managed-by` | `ssp-operator` | `cdi-controller` |
| `dataImportCron` label | absent | `rhel9-image-cron` |
| `spec.source` | `pvc {name: win2k22}` | `snapshot {name: rhel9-…}` |
| Ready | `False` — "PVC not found" | `True` |

SSP creates the placeholder; the cron takes ownership, relabels it, and rewrites
`spec.source` from `pvc` to `snapshot`.

The six built-in templates are **not** at risk: `spec.dataImportCronTemplates` is
empty on a stock cluster — they live in HCO itself and appear only in `status`,
flagged `commonTemplate: true`. Custom entries coexist.

## Preflight Check

```bash
./utilities/preflight.sh "${ENV:-sandbox}"

# Confirm the image reference is set (should point at win2k22-cis-l1-golden)
grep -h '^quay_windows_image' inventory/group_vars/*/connection.yml
```

`quay_username` and `quay_password` come from the vaulted
`playbooks/group_vars/all/secrets.yml`; the playbook asserts both and rejects
`CHANGEME`.

## Before linking a NEW tag: prove the image is actually hardened

**`com.redhat.cis.level=L1` is the producer's INTENT, not a measurement of the
disk.** `publish_windows_containerdisk.yml` defaults to `cis_level=L1` and the
`win2k22-cis-l1-golden` repository name, so the label says what the operator
meant. Nothing reads the media back.

That is not a theoretical gap. **#358 spent two rebuilds on it**, because a
running guest cannot tell you whether the image was unhardened or whether
something stripped the hardening after boot. Reading the published media settles
it with no cluster, no VM, and no credential beyond the quay pull:

```bash
pip install regipy   # once; qemu-img and ntfsprogs are already present
utilities/inspect-golden-image.py \
  --image "$(grep '^quay_windows_image' inventory/group_vars/sandbox/connection.yml | cut -d'"' -f2)"
```

Exit `0` means the image carries the hardening; exit `1` means it does not, and
you should **not link it**. The controls it reads are deliberately only ones
that *cannot* be set on a clean install — #358's original evidence was
ambiguous precisely because nine "compliant" controls were stock Windows values,
so a check that could pass on a default install would be worthless here.

It also prints **provenance** — how many `sysprep` runs the disk records and
when. That is what caught image.builder.pipeline#91: a disk sysprepped exactly
once, on 2026-09-05, published two days later as
`win2k22-cis-l1-golden:20260907-0516`.

> The pull is ~9 GiB and the conversion needs ~70 GiB of scratch, so this is a
> **per-new-tag** check, not something to run before every link. Tags are
> immutable — verify a tag once and the answer holds for ever.

**Never pipe the run through `tee`.** In a pipeline the exit status comes from
`tee`, not `ansible-playbook`, so a failed run reports success.

## Run

```bash
./utilities/run-ansible.sh playbooks/link_windows_image.yml -i inventory --limit sandbox \
  -e target_env=sandbox \
  --vault-id sales.demos@~/secrets/.vault_pass_sales_demos
```

And the reversal, which ships in the same change because this touches a
cluster-wide boot source:

```bash
./utilities/run-ansible.sh playbooks/link_windows_image.yml -i inventory --limit sandbox \
  -e target_env=sandbox -e windows_image_link_state=absent \
  --vault-id sales.demos@~/secrets/.vault_pass_sales_demos
```

`absent` removes the cron template and the pull secret; `win2k22` returns to its
empty SSP placeholder state.

## Verify it in the EE before merging a change

See `/sales-demos-verify-ee` for why and how. The one command:

```bash
utilities/run-in-ee.sh playbooks/link_windows_image.yml \
  -i inventory --limit sandbox -e target_env=sandbox \
  --vault-id sales.demos@~/secrets/.vault_pass_sales_demos
```

## Reading the result

| Symptom | Cause | What to turn |
|---|---|---|
| Fails at the `quay_windows_image` assert | Image reference empty or placeholder | Set `quay_windows_image` in `connection.yml` to the current CIS L1 tag. |
| DataSource never reaches Ready | The importer cannot pull | Check the importer pod in `openshift-virtualization-os-images`; a private-repo auth failure surfaces there, not in the DataSource. |
| Ready, but the backing volume never becomes usable | Snapshot still materializing | Wait. Cloning from a snapshot that is not `readyToUse` is the slow-build case `sales-demos-verify-env` exists to catch. |
| VM still will not boot after a green run | Something other than the boot source | `sales-demos-provision`, then the VM's own events. |

## Verify against the cluster, not the recap

```
mcp__openshift-<env>__resources_get  cdi.kubevirt.io/v1beta1 DataSource win2k22
  namespace: openshift-virtualization-os-images

mcp__openshift-<env>__resources_list  snapshot.storage.k8s.io/v1 VolumeSnapshot
  namespace: openshift-virtualization-os-images

mcp__openshift-<env>__resources_get  hco.kubevirt.io/v1beta1 HyperConverged kubevirt-hyperconverged
  namespace: openshift-cnv
# Check spec.dataImportCronTemplates[*].metadata.name

mcp__openshift-<env>__resources_list  cdi.kubevirt.io/v1beta1 DataImportCron
  namespace: openshift-virtualization-os-images
```

`win2k22` should report `Ready=True`, and the cron template should be listed in
`spec` alongside nothing else unless someone added another.

**`Ready=True` is not the check. It is the check that lied for two days**
(#358). A DataSource stays Ready for ever once populated, whatever
`quay_windows_image` is later set to, and the HyperConverged entry above shows
the tag that was *asked for* — not the one imported. Ask what is actually
served:

```
mcp__openshift-<env>__resources_get  cdi.kubevirt.io/v1beta1 DataVolume win2k22-initial-import
  namespace: openshift-virtualization-os-images
# Check spec.source.registry.url
```

That must equal `docker://` plus `quay_windows_image` from this environment's
`connection.yml`. If it does not, every Windows clone is booting the wrong
image and the compliance report is describing something nobody chose. The
playbook now asserts this itself on every run, so a green run is the same
statement — this is how to confirm it by hand.

## Where this sits

1. `sales-demos-setup` — runs `setup.yml`, which installs CNV, links the RHEL 9
   golden image, links the Windows golden image (stage 3), applies the AAP
   config, and verifies the environment.
2. **This skill** — fills the Windows boot source from the published CIS L1 image.
   Now part of `setup.yml` as stage 3 of 12. Also runnable standalone, or through
   the `Cluster Day 0` AAP workflow which includes it.
3. `sales-demos-provision` — build the demo VMs, now including `os_type=windows`.