-
Epic
-
Resolution: Won't Do
-
Critical
-
None
Epic Goal
Determine if we should be building a customized API that aggregates all of the Klusterlet and ACM add-on lifecycles into a singular API or if we should be integrating this capability into TALM (Toplogy Aware Lifecycle Manager)
Why is this important?
- For an operator like TALM, customers are already acquianted with interacting with cluster and operator upgrades via that workflow. ACM rolling upgrade is similar in nature, so it may make sense to roll this functionality into TALM as the entry point, and have TALM be the operator that handles all lifecycle rollout functionalities.
Scenarios
...
Acceptance Criteria
...
Dependencies (internal and external)
- ...
Previous Work (Optional):
- ...
Open questions:
- …
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>
- blocks
-
-
- Closed
-
