Epic Goal

• The goal of this epic is to support Windows Containers in environments with restricted networks where hosts are intentionally impeded from reaching the internet, also known as disconnected or "air-gapped" clusters.

Why is this important?

• The motivation here is to expand the Windows containers production use case, enabling users to add Windows nodes and run workloads easily and successfully in disconnected clusters. This is an extremely important ask for customer environments where Windows nodes must pull images from air-gapped registries for security reasons.

• The added benefit here is that the changes proposed in this enhancement are not restricted to disconnected environments; users in connected clusters can take advantage of this mirror registry support. This would allow better performance as images can be stored in registries closer to the production environment, reducing pull times for large Windows container images, in addition the security benefits of restricted networks.

Scenarios

There are 4 different workflows that affect the disconnected use case.
1. A cluster creator brings up a new disconnected cluster and configures mirror registry settings at install time
2. A cluster administrator introduces new mirror registry settings or changes exisiting ones during runtime
This would occur through the creation, deletion, or update IDMS/ITMS resources.
3. A cluster administrator transitions a connected cluster with existing mirror registry settings to a disconnected cluster
4. A cluster administrator transitions a connected cluster without existing mirror registry settings to a disconnected cluster

Acceptance Criteria

• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• WMCO consumes global mirror registry settings from existing platform resources
• WMCO configures registry settings for the containerd runtime on Windows nodes such that it enables Windows nodes to pull images in disconnected environments

Dependencies (internal and external)

1. There already exists a protocol for users to publish registry mirroring configuration, namely `ImageDigestMirrorSet` (IDMS), `ImageTagMirrorSet` (ITMS) cluster resources. These are consumed by OpenShift components like the Machine Config Operator (MCO) to apply the settings to Linux control-plane and worker nodes, Windows worker nodes do not currently consume or respect mirror registry settings when pulling images. This effort will work to plug feature disparity by making the WMCO aware of mirror registry settings at operator install time and reactive during its runtime.

Previous Work (Optional):

1. WINC-662

Open questions::

1. None at this time

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>