Overview

Add configuration options to specify custom storage locations for OCI artifacts in CRI-O, similar to how additionalimagestores works in containers/storage.

Current Behavior

• Default path: <graphroot>/artifacts/ (typically /var/lib/containers/storage/artifacts/)
• Implementation: internal/ociartifact/store.go:47 - hardcoded as filepath.Join(rootPath, "artifacts")
• Limitation: No way to use separate storage or pre-populated read-only artifact stores

Use Cases

1. Separate Storage Devices

Store large ML models on dedicated high-capacity storage separate from OS/container images.

• Prevents artifacts from filling root filesystem
• Allows specialized storage (HDD for artifacts, SSD for images)

2. Pre-populated Artifact Cache

Pre-populate shared read-only artifacts across cluster nodes (via NFS/distributed filesystem).

• Reduces network bandwidth and registry load
• Faster pod startup (no download required)
• Ideal for air-gapped environments

3. Multi-tier Storage

Fast local storage for hot artifacts, slower network storage for archives.

• Performance optimization for frequently accessed artifacts
• Cost-effective storage tiering

4. Immutable Infrastructure

Nodes use baked-in or verified artifact sources, preventing dynamic downloads.

• Enhanced security (no external registry access)
• Compliance with regulatory requirements

5. Edge/IoT Deployments

Limited local storage with read-only artifacts on removable media.

• Minimizes local storage requirements
• Offline artifact delivery via USB/SD cards

Related

• Speed up AI model-loading by having a pre-download mechanism for OCI volumes #9583: Pre-pull mechanism for OCI artifacts (complementary feature)
• Existing pattern: additionalimagestores in containers/storage