Feature Overview (aka. Goal Summary)  

Before extension installation, OLM needs to introspect the dependencies of an extension and present a preview of the resolution result to the user to let the user confirm they are ok with this.

Goals (aka. expected user outcomes)

• Make OLM's dependency model more intuitive, flexible and transparent.
• Make it easier for admins to preview what is going to be resolved.

Requirements (aka. Acceptance Criteria):

Use Cases (Optional):

• Before committing to extension installation, a cluster admin can preview the resolution result of the dependencies of an extension so he/she can decide if it meets his/her expectation.

Definition of Done / Acceptance criteria

• all requirements required for MVP are implemented

Background, and strategic fit

OLM dependency resolution is too inflexible for many Operator authors who want to be more specific about the Operator they depend on. APIs are not precise enough to hit on a particularly well tested dependency. It is also too hard for cluster admins to discover what is about/what has been installed as a dependency, additional Operators being installed comes as a surprise and the relationship is not made clear.

This is part of a larger effort to re-design vital parts of the OLM APIs and conceptual models to fit the use case of OLM in managed service environments, GitOps-controlled infrastructure and restrictive self-managed deployments in Enterprise environments. You can learn more about it here: https://docs.google.com/document/d/1LX4dJMbSmuIMn98tCiBaONmTunWR6zdUJuH-8uZ8Cno/edit?usp=sharing

Open Questions to Answer (Optional):

• Do we want to cover setting channel and approval strategy for dependencies in this or not?
• What are the other gaps for Red Hat Operators using OLM dependencies?

Out of Scope

High-level list of items that are out of scope.  Initial completion during Refinement status.

Documentation Considerations

• TBD