Feature Overview

OLM v1 delivers significant improvements for managing operators and complex workloads on OpenShift, including fully declarative, GitOps-friendly workflows, precise control over update paths, and simplified user-facing APIs.

Adoption of OLM v1 for ACM means multiple things:

1. Each ACM operator should eventually work with OLMv1.  It may mean we have to support both OLM v0 and v1 for a period of time.  The OLM v1 release is an initial phase so it will be expected our adoption could be in phases also.
2. Many of the ACM operators act as an operator of operators that manages ACM components as operators.  This mechanism of managing our internal components needs to be evaluated to determine how olmv1 impacts our installation framework.
3. A feature in the Governance pillar is the OperatorPolicy which provides enhanced support for olm v0, but no compatiblity with OLM v1.  OLM v1 does not appear to need any special handling at least in the current phase, so adoption could move back to just using ConfigurationPolicy. How we adopt v1 needs to be clarified.

Goals

This Section: Provide high-level goal statement, providing user context
and expected user outcome(s) for this feature

• Achieve ACM provided goals.  Our goals are listed above in the overview.
• Achieve Red Hat OLM v1 goals. OLM v1 testing and adoption in a continous pipeline, potentially in phases as more OLM v1 features are provided. OCP 4.18+ focus where OLM v1 support is provided.  Additional focus as provided by Red Hat OLM teams

Requirements

This Section: A list of specific needs or objectives that a Feature must
deliver to satisfy the Feature.. Some requirements will be flagged as MVP.
If an MVP gets shifted, the feature shifts. If a non MVP requirement slips,
it does not shift the feature.

(Optional) Use Cases

This Section:

• Main success scenarios - high-level user stories
• Alternate flow/scenarios - high-level user stories
• ...

Questions to answer

• ...

Out of Scope

• …

Background, and strategic fit

This Section: What does the person writing code, testing, documenting
need to know? What context can be provided to frame this feature?

Assumptions

• ...

Customer Considerations

• ...

Documentation Considerations

Questions to be addressed:

• What educational or reference material (docs) is required to support this
  product feature? For users/admins? Other functions (security officers, etc)?
• Does this feature have a doc impact?
• New Content, Updates to existing content, Release Note, or No Doc Impact
• If unsure and no Technical Writer is available, please contact Content
  Strategy.
• What concepts do customers need to understand to be successful in
  [action]?
• How do we expect customers will use the feature? For what purpose(s)?
• What reference material might a customer want/need to complete [action]?
• Is there source material that can be used as reference for the Technical
  Writer in writing the content? If yes, please link if available.
• What is the doc impact (New Content, Updates to existing content, or
  Release Note)?