OCP/Telco Definition of Done
https://docs.google.com/document/d/1TP2Av7zHXz4_fmeX4q9HB0m9cqSZ4F6Jd4AiVoaF_2s/edit#heading=h.gaa58bzbvwde
Epic Template descriptions and documentation.
https://docs.google.com/document/d/14CUCEg6hQ_jpsFzJtWo29GfFVWmun2Uivrxq3_Fkgdg/edit
ACM-wide Product Requirements (Top-level Epics)
https://docs.google.com/document/d/1uIp6nS2QZ766UFuZBaC9USs8dW_I5wVdtYF9sUObYKg/edit

*<--- Cut-n-Paste the entire contents of this description into your new
Epic --->*

Epic Goal

Many users and Red Hat components would like to use AddonTemplate to install operators today. To provide a better support for operator installation, we need to enhance the underlying API manfestwork to cover the below use cases.

1. Install Operators on a fresh new OCP.
2. The Operators were installed from ACM and then uninstalled from ACM.
3. The Operators were installed from OCP UI and then uninstalled from ACM. (Should we not plan to support)
4. The Operators were installed from ACM and then uninstalled from OCP UI, with OperatorGroups left in the namespace. When trying to install the Operators from ACM again, should avoid applying OperatorGroup since there’s already one in the same namespace.
5. The Operators were installed from OCP UI and then uninstalled from OCP UI, with OperatorGroups left in the namespace. When trying to install the Operators from ACM again, should avoid applying OperatorGroup since there’s already one in the same namespace.
6. The Operators are already installed, should avoid installing the Operators again from ACM.

Key issues to resolve:

1. Enhance the manifestwork API to avoid applying OperatorGroup when there’s already one in the same namespace.
2. How is an operator considered installed?

Why is this important?

...

Scenarios

...

Acceptance Criteria

...

Dependencies (internal and external)

1. ...

Previous Work (Optional):

1. ...

Open questions:

1. …

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 - Doc issue opened with a completed template. Separate doc issue
  opened for any deprecation, removal, or any current known
  issue/troubleshooting removal from the doc, if applicable.
• Considerations were made for Extended Update Support (EUS)