Epic Goal

• define CLI requirements and structure and approach

Why is this important?

• OLM Operator does not want to be in the business of managing RBAC: tooling will be required to smooth this rough UX edge
• We want to offer off-line OLM primitives such as unpack, install, upgrade, delete, render bundle, etc. to enable other use-cases, e.g. manifest generation for microshift payloads
• Improve usability of OLM by making it easy-to-use and easy to on-board

Some Scenarios

1. User can introspect the bundle manifests as well as render it with the desired configuration for visual inspection ahead of installation:
   1. RBAC requirements
   2. Deployment pod template definition
   3. Ingress or other network related resource configuration and possible impact
2. User can get status information beyond ClusterExtension .status.conditions, e.g. the client could derive the constituent resources and probe their status, as well as resource usage, metrics, etc.
3. Enables a more imperative usage model (e.g. to inspect and approve RBAC)
4. Complementing OLM Operator by either stamping out required RBAC before installation (through introspection) or as the required RBAC is advertised in the ClusterExtension .status.conditions or wherever it will be advertised
5. Enables users to quickly get started with OLM by finding it in their regular package manager (brew, apt, dnf, chocolatey, etc.) and providing easy on-board commands to install the operator on the cluster and quickly explore packages

Acceptance Criteria

• TBD in Brief

Dependencies (internal and external)

1. It may depend on other Briefs around security and policy

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>