-
Feature Request
-
Resolution: Unresolved
-
Normal
-
None
-
None
-
None
-
None
-
Product / Portfolio Work
-
None
-
None
-
None
-
None
-
None
-
None
-
-
None
-
None
-
None
-
None
-
None
1. Proposed title of this feature request
Extend oc-mirror capabilities or create a new utility to manage and serve OCI Artifacts for small edge deployments.
2. What is the nature and description of the request?
Simplify the management of different artifacts needed for deployment in a air-gaped environment, without requiring the L1 operators and field engineers to be aware of different tools and specific workflows and bring portability across platforms using a single binary approach.
oc-mirror could have its capabilities extended, or eventual a new utility to be developed, to support:
- through a declarative approach, define application packages that may contain OCI artifacts like container images, helm charts, container signatures, files and potentially ML Models.
- Ability to mirror/copy those OCI artifacts and not only container images.
- Within the same context/CLI, have ability to serve as small OCI registry and store the artifacts mentioned above. Note that mirror-registry does require a different process to be installed, which could impact on end-user experience at edge and far-edge.
- package all in a single archive, that could be transferred across and used with RHDE or OpenShift.
- Support to be build the package on Linux systems but also to be served on Windows hosts without WSL.
3. Why does the customer need this? (List the business requirements here)
Partners and customers require a solution that addresses the following core business drivers:
- Simplify Field Deployments: The primary users are often field engineers or end-customers who are IT generalists, not Kubernetes experts. They need a simple, reliable tool to deploy applications in disconnected environments without a steep learning curve.
- Support Constrained Edge Devices: The target environments are often resource-constrained Industrial PCs (IPCs). The required solution must be a lightweight, self-contained utility with a minimal footprint and no heavy dependencies.
- Enable an Application-Centric Workflow: The need is to package and transport specific application payloads (a small set of images and manifests), which is a fundamentally different and more frequent task than mirroring an entire platform.
- Multi-platform: Capable on running on modern Linux systems but also be used to serve artifacts on brownfield Windows-based deployments.
4. List any affected packages or components.
potentially oc-mirror and mirror-registry, but maybe we are talking about a new utility here.