Feature Overview (aka. Goal Summary)  

A new mechanism to filter (disable/hide) operator packages by channels and bundle versions within mirrored OpenShift catalogs on the OLM (Operator Lifecycle Manager) cluster side, based on artifacts generated by oc-mirror.  

This will address the issue of invisible/missing operators in disconnected environments without requiring oc-mirror to rebuild catalogs.

Goals (aka. expected user outcomes)

1. Improved mirroring reliability:

• Eliminate the issue of operators disappearing from mirrored catalogs in disconnected OpenShift environments.
• Simplify the mirroring process to improve the stability and reliability of mirrored catalogs, reducing the risk of unintended side effects

2. Improved mirroring performance:

• Reduce disk space and network bandwidth requirements during the mirroring process for operator catalogs, only mirroring the packages (by channels/versions) specified by the customers.
• Improve oc-mirror performance by removing the catalog rebuilding step.

3. Improved security:

• Enhance the security posture by eliminating the need for oc-mirror to modify catalog images.
• Allow for the verification of operator catalog signatures.

4. Improved engineering maintainability:

• Provide a long-term and sustainable solution to the problem.
• Allow for a single catalog version to be used for both connected and disconnected environments.

Background

Disconnected OpenShift customers are facing significant challenges due to operators disappearing from their mirrored Certified and Community catalogs, hindering ISV solution validation and OpenShift upgrades.  The current manual workaround is unsustainable, necessitating a permanent solution.  

To address this, we propose filtering operators on the OLM cluster side, utilizing artifacts generated by oc-mirror, rather than rebuilding catalogs.  This approach aims to enhance security, performance, and stability. 

Importantly, this issue stems from bundle metadata problems during oc-mirror catalog rebuilds, which our proposed solution avoids by allowing oc-mirror to simply copy the original Red Hat catalog.

See additional contexts and histories in this doc at Solution 9: Addressing missing Operator metadata in mirrored catalogs 

Requirements (aka. Acceptance Criteria):

• Artifact generation:
  • oc-mirror generates an artifact (e.g., a configuration file, manifest) that defines the operator packages, channels, and bundles to be filtered
  • The artifact must be easily consumable by the OLM
  • The artifact must be able to specify specific channels, bundles, or entire operators

• OLM filtering mechanism:
  • OLM implements a mechanism to read and apply the oc-mirror generated artifact
  • OLM can disable/hide the specified operators, channels, and bundles from the catalog displayed in the CLI and UI based on oc-mirror generated artifact 
  • The filtering mechanism is configurable and reversible (declarative)
  • The filtering mechanism should not alter the original catalog image
  • The filtering mechanism works with signed catalogs

• Security:
  • The solution maintains the security integrity of the mirrored catalogs
  • The solution supports operator catalog signature mirroring/verification (Sigstore feature).

• ...
•  

Questions to Answer (Optional):

Include a list of refinement / architectural questions that may need to be answered before coding can begin.  Initial completion during Refinement status.

<your text here>

Documentation Considerations

Provide information that needs to be considered and planned so that documentation will meet customer needs.  If the feature extends existing functionality, provide a link to its current documentation. Initial completion during Refinement status.

<your text here>

Interoperability Considerations

Which other projects, including ROSA/OSD/ARO, and versions in our portfolio does this feature impact?  What interoperability test scenarios should be factored by the layered products?  Initial completion during Refinement status.

<your text here>