The disconnected OpenShift upgrade preflight

A disconnected cluster depends on more than an imported release image. Upgrade success requires the cluster to fetch every required image, accept the appropriate signatures and trust configuration, and reach a supported release target.

Use this checklist before starting a planned OpenShift update. Commands show the inspection workflow. The exact update commands, resource types, and compatibility rules depend on your OpenShift release and mirror tooling version.

1. Record the current state#

oc get clusterversion
oc get clusteroperators
oc get machineconfigpools
oc get nodes -o wide

Capture the current release image, operator states, and degraded or progressing conditions. Investigate persistent cluster operator failures before you introduce another change.

Check the current release payload and candidate version using oc adm release info when you have a release pull specification that can be resolved from the machine running oc.

oc adm release info IMAGE_PULLSPEC

IMAGE_PULLSPEC is a placeholder. Confirm that the image reference points at the intended release in your environment.

2. Confirm the update path#

The target release must be supported as an update from your current release. A mirrored payload does not prove that the update edge is supported.

When you use the OpenShift Update Service (OSUS), review the graph data version and verify that its recommendations include the intended target. OSUS provides update recommendations inside a disconnected environment.

oc get updateservice -A
oc get clusterversion version -o yaml

Document the current version, target version, source of the supported update edge, and the maintenance window.

3. Inspect mirror policies#

oc get imagedigestmirrorset
oc get imagetagmirrorset
oc get imagecontentsourcepolicy

A cluster may have legacy ImageContentSourcePolicy objects as well as newer ImageDigestMirrorSet and ImageTagMirrorSet resources. Review the resources appropriate to your installed release. Avoid deleting legacy policies until their purpose and replacement have been established.

Verify that registry credentials, certificate authority trust, and network paths from the cluster to the registry are in place.

4. Validate image and catalog content#

Release payloads, operator catalogs, and their dependent images have separate lifecycle requirements. A mirrored release does not necessarily include every operator image the cluster uses.

oc get catalogsource -A
oc get subscriptions -A
oc get installplans -A

Inventory installed operators. Confirm that the required operator versions and dependencies are present in the local catalogs. Check catalog health and confirm that the catalog references the correct local registry.

For oc-mirror v2, review the generated cluster-resources directory for mirror policies and catalog resources. Its directory conventions differ from oc-mirror v1.

5. Test the critical dependencies#

Before authorizing the upgrade, confirm the following:

• The mirror registry is reachable from the relevant cluster nodes.
• The expected release and operator image digests exist in the registry.
• Registry authentication and the relevant CA trust are correct.
• Cluster operators and machine config pools are in a known state.
• Required workload maintenance, backups, and rollback procedures are understood.
• The upgrade sequence is valid for the installed release.

6. Keep evidence with the change#

Save the exact release pull specification, selected update edge, mirror run artifacts, catalog inventory, and preflight output in the change record. This makes it possible to explain a failed image pull or operator reconciliation later.

References: Red Hat: Updating in disconnected environments and Red Hat: Disconnected operations and oc-mirror. Use the documentation for your own cluster version when executing an upgrade.