Feature Overview (aka. Goal Summary)  

Unprivileged cluster tenants can discover installed operators/extensions and the associated services that are made available to them in a resource-efficient way.

Goals (aka. expected user outcomes)

• Cluster tenants with limited permissions can discover installed operators/extensions available to them as a single entity that ties together vital metadata (description, documentation, support, feature annotations) and the provided APIs.

• Cluster tenants with limited permissions can learn the information about operators/extensions availability in the scope where they can access in a resource-efficient way in a cluster with thousands of namespaces.

Requirements (aka. Acceptance Criteria):

• Note: scopes are cluster and namespace.

• A user (who has sufficient permission) can use the top-level extension API to define a list of namespaces where the extension is discoverable.
  • the list can either be specified as a regular list construct or the result of a label selector query.

• There is a way for a user to retrieve a list of operators in a scope, where
  • For each operator listed, it is watching the relevant scope target
  • For each operator listed, the user has at least 1 permission for at least 1 of the APIs provided by the operator
  • For each operator listed, its metadata is included. 
    • In the current OLM, users have access to these metadata (from different API objects) for an installed operator version:
      • channel
      • catalog (source)
      • version 
      • provided APIs
      • required APIs (if any)
      • relatedImages (as in image ref) 
      • description (as in markdown) 
      • displayName 
      • icon 
      • keywords 
      • links: name, url 
      • maintainers: email, name 
      • provider: name 
      • All “annotations” are currently stored in “metadata.annotations” of CSV, e.g., (non-exhaustive)
      • alm-examples, e.g. [ {apiVersion: camel.apache.org/v1, kind: Build, metadata: Unknown macro: {labels}, spec: {}}]
      • operatorframework.io/initialization-resource
      • operators.operatorframework.io/internal-objects
      • capabilities (e.g. Seamless Upgrades)
      • categories (e.g. Integration & Delivery)
      • description (e.g. “Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes.”)
      • operatorframework.io/suggested-namespace
      • operatorframework.io/suggested-namespace-template
      • operators.openshift.io/valid-subscription
      • “old” and “new” infrastructure-features

• There is a way for a user to retrieve a list of APIs provided by operators in a scope, where
  • For each API listed, at least one operator that reconciles the API is watching the scope target
  • For each API listed, the user has at least 1 permission for that API
  • For each API listed, it indicates which operator provides it
  • For each API listed, its metadata is included.
    • provided API metadata (similar to what’s in the CSV):
      • group
      • kind
      • version
      • description
      • displayName

• These list operations are scalable (don’t reimplement copied CSVs).

Anyone reviewing this Feature needs to know which deployment configurations that the Feature will apply to (or not) once it's been completed.  Describe specific needs (or indicate N/A) for each of the following deployment scenarios. For specific configurations that are out-of-scope for a given release, ensure you provide the OCPSTRAT (for the future to be supported configuration) as well.

Use Cases (Optional):

User scenarios:

• With oc/kubectl, I can issue a CLI command to see a list of Operators and their provided APIs that are available to me, which I can consume/use by creating CR objects from those provided APIs for my app in my project (namespace).

• In the console (UI works not in scope), I navigate to the “Developer Catalog” page in my project (namespace) and see a list of provided APIs from an operator (grouped together) that are available to me, which I can consume/use by creating CR objects from those provided APIs for my app in my project (namespace).

• In the console (UI works not in scope), I navigate to the “Installed Operators” page in my project (namespace) and see a list of Operators and their provided APIs that are available to me, which I can consume/use by creating CR objects from those provided APIs for my app in my project (namespace).

• In the above three scenarios, I can see metadata (e.g., descriptions, docs links, support, valid subscription info, capability levels) of the operator itself and the metadata (e.g., descriptions) of those provided APIs to guide me on how to get started or find supports either in CLI or UIs.

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>

Out of Scope

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

<your text here>

Background

Upstream engineering brief: https://docs.google.com/document/d/1_danU7GP-YUMspdZ2Fl44nriJRp3SgyFRwqrvOsrivY/edit?usp=sharing

Customer Considerations

Provide any additional customer-specific considerations that must be made when designing and delivering the Feature.  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>