-
Feature Request
-
Resolution: Unresolved
-
Normal
-
None
-
None
-
None
1. Proposed title of this feature request
Extend oc-mirror capabilities to manage and serve OCI Artifacts.
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.
oc-mirror could have its capabilities extended 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.
3. Why does the customer need this? (List the business requirements here)
Customers and partners working with edge, far-edge, which are normally also air-gaped/disconnected and high regulated, are working with dozens and hundreds of deployments in the field, which are usually installed by their field engineers and sometimes by their end customers as well. Those field engineers are normally IT generalists, and not necessarily specialists or holding advanced expertise with Linux or Kubernetes deployments. Simplifying their user experience is a key component for successful deployments at the edge.
4. List any affected packages or components.
oc-mirror and mirror-registry