/create-cpo-override

description: Interactively create CPO image overrides — resolves images, verifies fixes, edits overrides.yaml, and prepares a PR

Create CPO Override

Synopsis

/create-cpo-override

Description

Interactively creates control-plane-operator (CPO) image override entries in `hypershift-operator/controlplaneoperator-overrides/assets/overrides.yaml`. Automates image discovery, fix verification, YAML editing, and PR preparation so the result is compatible with `/validate-pr-override-images`.

Prerequisites

• `skopeo` installed
• `oc` installed (for `oc adm release info`)
• `gh` CLI authenticated
• Local git repo has relevant release branches fetched (`git fetch --all`)
• Internet access to quay.io and the Cincinnati API

Implementation

Follow the steps below **in order**. Each step builds on the previous one. Use `AskUserQuestion` for multi-choice prompts where indicated. For free-form inputs, ask the user directly in conversation.

---

Step 0 — Detect pull secret

Many OCP payload images require authentication. Before any image operations, probe for a working pull secret:

1. Try a lightweight `skopeo inspect` against a known release payload image (e.g. `quay.io/openshift-release-dev/ocp-release:4.18.0-multi`). If it succeeds, the container runtime's default auth is sufficient — no extra flags needed. 2. If that fails, check if `$PULL_SECRET` is set and points to an existing file. If so, retry with `--authfile "$PULL_SECRET"` (and use `-a "$PULL_SECRET"` for `oc adm release info`). Use this authfile for all subsequent image operations. 3. If neither works, ask the user to provide a path to a pull secret file. If they don't have one, warn that payload-sourced images (Sources 1 & 2) will be unavailable and only Konflux images (Source 3, public on `quay.io/redhat-user-workloads/`) can be resolved automatically.

---

Step 1 — Gather inputs

Collect the following from the user. Ask all questions up front (or in logical groups) rather than one at a time.

1a. Platform(s)

Ask the user which platform(s) to override.

Options: `aws`, `azure`, or `both`.

1b. Jira ticket

Ask for the parent Jira ticket that motivates the override (e.g. `OCPBUGS-86238`). This is used in comment markers and the commit message.

1c. Branches

Ask which OCP minor branches need overrides (e.g. `4.20, 4.21`).

1d. Version range per branch

For each branch, ask the user which z-stream versions to override. Accepted formats:

| Input | Meaning | |-------|---------| | `4.20.0-4.20.24` | Explicit range | | `all` | Every z-stream from `X.Y.0` through the highest z-stream in the Cincinnati `fast-X.Y` channel | | `4.20.15` | Single version |

When the user says **`all`**, resolve the range as follows:

curl -sH 'Accept: application/json' \
  "https://api.openshift.com/api/upgrades_info/v1/graph?channel=fast-${BRANCH}&arch=multi" \
  | python3 -c "
import json, sys
data = json.load(sys.stdin)
versions = [n['version'] for n in data.get('nodes', [])
            if n['version'].startswith('${BRANCH}.')]
zs = sorted(int(v.split('.')[2]) for v in versions)
print(max(zs))
"

Then generate every z-stream from `X.Y.0` through `X.Y.<max_z>` **inclusive** (Cincinnati skips some z-streams like 4.20.7, 4.20.9 — clusters can still run them, so include them all).

1d-ii. Verify the next z-stream via development cutoff dates

**This is critical to avoid upgrade regressions.** If a customer is on an overridden version (e.g. 4.22.3) and upgrades to the next z-stream (e.g. 4.22.4), the override no longer applies. If that next z-stream does **not** contain the fix in its payload, the customer regresses.

To determine whether the next z-stream after the override range needs to be included, check the **development cutoff date** for that version against the PR merge dates.

**If the `productpages` MCP server is available**, use it:

1. Search for the z-stream release entity:

   search_entities(q="OpenShift X.Y.z", kind="release")

2. Browse the schedule for the next z-stream's development cutoff:

   browse_schedule(entity_id=<id>, q="X.Y.<max_z+1>")

3. Find the task named `X.Y.<max_z+1> Development Cut Off` and note its `date_finish`. 4. Compare with each required PR's merge date (from `gh pr view --json mergedAt`).

If **all** PRs merged **before** the cutoff date, the next z-stream will include the fixes — no override needed for it. Add a comment in `overrides.yaml` noting this (e.g. "4.22.4 does not need an override: both PRs merged before the development cutoff").

If **any** PR merged **after** the cutoff date, extend the override range to include that z-stream and repeat the check for the one after it.

**If the `productpages` MCP server is NOT available**, warn the user and ask for the cutoff date:

> ⚠️ **Cannot verify development cutoff dates** — the Product Pages MCP server > is not connected. Please check the development cutoff date for > `X.Y.<max_z+1>` at https://pp.engineering.redhat.com and provide it here so > I can verify the override range is complete.

When the user provides the cutoff date, compare it against the PR merge dates (same logic as above). If any PR merged after the cutoff, extend the override range and ask for the next z-stream's cutoff date. Repeat until the range is safe.

1e. Required PRs

Ask which GitHub PRs must be present in the override image. Accept PR URLs (e.g. `https://github.com/openshift/hypershift/pull/8593`) or plain numbers (e.g. `8593`). Multiple PRs can be comma-separated.

PRs can be specified per-branch or globally (applied to all branches). If a PR is a cherry-pick, the user should provide the **branch-specific** PR number.

1f. Image per branch (optional)

Ask whether the user wants to provide specific images or have them auto-resolved. If auto-resolved, proceed to Step 2.

---

Step 2 — Auto-resolve images

For each branch that needs an image, try