Goal

Enable configuration of additional read-only image store locations in CRI-O, allowing users to configure shared image caches on high-performance or network-attached storage. This addresses the problem where multiple nodes redundantly pull the same container images from external registries, wasting network bandwidth and slowing down container startup times.

Why is this important?

• Multiple cluster nodes redundantly pull identical container images from external registries, consuming network bandwidth
• Cannot leverage shared network storage (NFS) or high-performance storage (SSD) for pre-populated image caches
• Air-gapped and edge deployments need pre-populated images without registry access
• Container startup times suffer from repeated image pulls instead of using local caches
• Root filesystem space consumed by duplicate images that could be shared across nodes

Scenarios

1. As a Cluster Admin, I want to pre-populate a read-only image cache on shared network storage (NFS), so that multiple nodes can share images without redundant pulls from external registries
2. As an Edge Deployment Operator, I want to use SSD-backed storage for frequently-used base images, so that container startup is faster and doesn't consume root filesystem space
3. As a Cluster Admin in an air-gapped environment, I want to pre-populate complete container images on nodes, so that pods can start without registry access

Acceptance Criteria

• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents
• ContainerRuntimeConfig API accepts additionalImageStores configuration with path field
• MCO generates correct storage.conf with additionalimagestores array in [storage.options] section
• container-libs/storage checks additional image stores first before pulling from registry
• Measurable container startup time improvement when using pre-populated image caches
• Feature works with shared storage (NFS) and high-performance storage (SSD)
• No regressions for standard image pulling behavior
• Feature behind TechPreviewNoUpgrade feature gate for OpenShift 4.22
• Clear documentation on image cache population strategies and storage configuration

Dependencies (internal and external)

1. Upstream: container-libs/storage - additionalimagestores feature already GA and stable
2. OpenShift: Enhancement proposal approval covering additionalLayerStores, additionalImageStores, and additionalArtifactStores API design
3. OpenShift: API merge in openshift/api before MCO implementation
4. Storage: Pre-populated image cache setup procedures for NFS/SSD storage
5. Documentation: Customer documentation for image cache population and storage setup
6. Related: OCPNODE-4050 (Additional Layer Store Support) - shares enhancement proposal and MCO implementation
7. Related: OCPNODE-4051 (Additional Artifact Store Support) - shares enhancement proposal and MCO implementation

Previous Work (Optional):

1. Proven pattern: containers/storage additionalimagestores feature (already implemented and stable upstream)
2. Similar to RHEL/Podman additionalimagestores configuration

Open questions:

1. Should we provide tooling or automation for populating image caches?
2. What are the recommended storage configurations (NFS parameters, SSD mount options)?
3. Should we implement image cache validation/health checks?
4. How should customers handle image cache updates and lifecycle management?
5. Should we support filtering which images go to which stores (similar to artifact stores)?

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Technical Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <already stable in container-libs/storage>
• DEV - Enhancement proposal merged: <link to openshift/enhancements PR>
• DEV - API changes merged: <link to openshift/api PR>
• DEV - MCO implementation merged: <link to openshift/machine-config-operator PR>
• 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>
• QE - Performance validation with shared storage: <link to validation results>
• DOC - Downstream documentation merged: <link to documentation PR>