Uploaded image for project: 'OpenShift Node'
  1. OpenShift Node
  2. OCPNODE-4051

Additional Artifact Store Support

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Unresolved
    • Icon: Normal Normal
    • None
    • None
    • None
    • None
    • Additional Artifact Store Support
    • To Do
    • Product / Portfolio Work
    • OCPSTRAT-2623Additional Artifact Store - 4.22 -TP
    • 100% To Do, 0% In Progress, 0% Done
    • False
    • Hide

      None

      Show
      None
    • False
    • Not Selected
    • None

      Goal

      Enable configuration of additional artifact storage locations in CRI-O, allowing users to specify where OCI volume images can be pulled from. This addresses the problem where large AI/ML models need to be stored on high-performance storage (SSD) separate from OS/container storage, improving pod startup times and storage utilization.

      Why is this important?

      • Large AI/ML models need to be stored on high-performance storage (SSD) for faster access
      • CRI-O currently hardcodes all artifacts to /var/lib/containers/storage/artifacts/, preventing use of dedicated storage
      • Cannot pre-populate shared artifact caches across cluster nodes for air-gapped or edge deployments
      • RHOAI workloads suffer from slow model loading and inefficient storage utilization
      • Root filesystem space consumed by large artifacts that should be on separate storage

      Scenarios

      1. As a RHOAI Platform Operator, I want to store large ML models on SSD storage, so that model loading is faster and doesn't consume root filesystem space
      2. As a Cluster Admin in an air-gapped environment, I want to pre-populate artifact caches on nodes, so that pods can start without pulling from external registries
      3. As an Edge Deployment Operator, I want to deliver artifacts via removable media (USB), so that edge nodes can operate offline without network connectivity

      Acceptance Criteria

      • CI - MUST be running successfully with tests automated
      • Release Technical Enablement - Provide necessary release enablement details and documents
      • ContainerRuntimeConfig API accepts additionalArtifactStores configuration with path and optional filter fields
      • MCO generates correct CRI-O config from API (storage.conf with additional_artifact_stores)
      • CRI-O resolves artifacts from additional stores in configured order
      • RHOAI team validates measurable performance improvement with SSD storage
      • Feature behind TechPreviewNoUpgrade feature gate for OpenShift 4.22
      • No regressions for existing artifact storage behavior
      • Documentation available with clear examples for common scenarios

      Dependencies (internal and external)

      1. Critical Path: CRI-O v1.36 release (April 2026) with PR #9702 merged
      2. Upstream: CRI-O PR #9702 (https://github.com/cri-o/cri-o/pull/9702) - adds additional_artifact_stores configuration
      3. OpenShift: Enhancement proposal approval covering both additionalLayerStores and additionalArtifactStores API design
      4. OpenShift: API merge in openshift/api before MCO implementation
      5. External: RHOAI team (Luca Burgazzoli) for performance validation
      6. Documentation: OSDOCS-17312 - Tech Preview feature documentation
      7. Backport consideration: If API work lands for 4.22, may need to backport CRI-O v1.36 PR to v1.35
      8. Related: OCPNODE-4050 (Additional Layer Store Support) - shares enhancement proposal and MCO implementation

      Previous Work (Optional):

      1. RFE-8441 - Related feature request for artifact pre-loading (separate feature, out of scope)
      2. Proven pattern: containers/storage additionalimagestores approach

      Open questions:

      1. Will CRI-O v1.36 be available in time for OpenShift 4.22? (April 2026 upstream release)
      2. Do we need to backport PR #9702 to CRI-O v1.35 if 4.22 timeline is tight?
      3. Should we defer upstream Kubernetes KEP until after Tech Preview validation?
      4. What are the performance benchmarks we should target with RHOAI validation?

      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: <link to CRI-O PR #9702>
      • 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 - RHOAI validation complete: <link to validation results>
      • DOC - Downstream documentation merged: <link to OSDOCS-17312 PR>

              sgrunert@redhat.com Sascha Grunert
              sgrunert@redhat.com Sascha Grunert
              None
              None
              None
              None
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated: