Goal
What is our purpose in implementing this? What are we enabling by doing this work? Time-box goals to 4-6 months.

As part of the Operator Portfolio Program, the primary goal is to establish a centralized Operator Inventory System that serves as the Official System of Record for all operators shipped with OpenShift/OLM. This system will enable the Program to mandate and govern OpenShift Initiatives effectively across the operator owner community.

The system will hold the following authoritative data:

• Official operator name
• Package name
• Current owner/maintainer of the operator
• Lifecycle and supportability information

This Inventory System will be incorporated into the operator delivery pipeline to provide automated, mandatory enforcement. At the beginning of the build process request, the pipeline will check the compliance of the inventory data and then check against other critical requirements/initiatives. The current list of these mandatory checks includes NetworkPolicies (NPs), OLM v1 compatibility, ubi-minimal usage, and FIPS compliance status. More to come as we evolve. 

Benefit Hypothesis:

What are the benefits (to Red Hat, eventually to customers, to the community, etc.)? Does it improve security, performance, supportability, etc? Why is work a priority?
We believe that the result of doing this work will be ...

We believe that implementing the Operator Inventory System will result in:

• Accelerated Compliance: Drastically reduce the time it takes to implement critical OpenShift Initiatives (e.g., security updates, new standards) across the entire operator portfolio.

• Improved Quality & Trust: Establish clear accountability and governance over operator lifecycles, leading to a more reliable and secure operator experience for our customers.

• Operational Efficiency: Eliminate manual tracking and data fragmentation, providing the Program Team with the data needed for accurate portfolio reporting and effective decision-making.

In summary: This work is a priority because it provides the foundational tooling to effectively mandate and govern the operator ecosystem, directly translating to higher quality for our users and greater efficiency for Red Hat internal operations.

Resources

Add any resources (docs, slides, etc.) pertinent to the definition of the work. These might not be known until later. Update as necessary.

Operator Portfolio Program Vision 

Responsibilities

Indicate which roles and/or teams will be responsible for contributing to the initiative and generally what they might be expected to do.

OLM team will be the team driving the development of the solution, in collaboration with the Konflux team.

Success Criteria

Provide some examples of how we will know if we have achieved the goal. What can be measured to determine success? What observable actions/outcomes that can be seen to determine success? Specific, Measurable, Achievable, fits within the Time-box.

By 31 March 2026 (should this state OCP release instead? 4.22), this inventory system will be fully in place and implemented in the system of choice.

Each operator will be checked at the time of initiating build process for compliance of required fields and functionality provided/implemented.

There should be a way to provide exception for non compliance by a feature. I.e. ubi-minimal - non-compliant, exception provided -> continue with the build process.

Results

Add results here once the Initiative is started. Recommend discussions & updates once per quarter in bullets.

Additional requirements:
List of additional criteria to enforce via the pipeline and the inventory system once established:

• Network Policies
• OLM v1
• ubi-minimal
• FIPS
• Lifecycle support, some examples: comply with {{{}olm.maxOpenShiftVersion{}}}] - we should require operator owners to provide value for this field. 
  • More details about future requirements can be found here OLM Layered Product Lifecycle Specification]