Proposed title of this feature request

Customers should be able to update without container registry in disconnected environments

What is the nature and description of the request?

The overall proposal is to add a mechanism to create an "upgrade bundle" that can be transported to the cluster offline (in an USB stick, for example) and applied without requiring an image registry server.

• I have a single node cluster effectively cut off from all other networking, and I want to be able to conveniently update that cluster despite the lack of access to image registries, local or remote.
• I have a multi-node cluster that could have a complete power outage, and I want it to recover smoothly from that kind of disruption, despite the lack of access to image registries, local or remote.

Non-goals

It is not a goal to not require a registry server for other operations. For example, installing the cluster can happen in an environment where there is external-to-the-cluster registry access, after which the cluster could be shut down, transported to a remote location, and turned back on. And adding a new user workload to an existing cluster or updating that user workload could happen via the cluster's internal image registry, but that registry will not be running to help when a single-node cluster is rebooting, and needs access to images before the cluster has come up enough to be hosting the cluster-internal registry again.

Why does the customer need this? (List the business requirements here)

The typical scenario is a far edge site of, or a factory site, where the OpenShift cluster is disconnected from the internet and where bringing up additional infrastructure for a image registry server isn't feasible.

The reasons that make additional infrastructure unfeasible are usually cost and limitations in the knowledge and expertise of the technicians that operates the site.

For example, in far edge sites customers frequently ask for single node configurations and reduced memory and CPU footprint in order to reduce the total cost of the sites. In this scenario additional infrastructure is a no go.

List any affected packages or components

• The oc tool needs to implement the creation of the upgrade bundle, e.g. by extending oc-mirror or otherwise.
• Something needs to implement upgrade bundle distribution within the target cluster, for the multi-node power-outage-recovery use-case.
• The machine config operator needs to support additional storage directories and image pinning, if upgrade bundle access is delivered via CRI-O access.
• All the OpenShift components need to avoid the Always image pull policy.