-
Epic
-
Resolution: Done
-
Blocker
-
None
-
ACM Backup/Restore Managed cluster restore
-
False
-
-
False
-
To Do
-
ACM-629 - Business continuity for the ACM Hub
Epic Goal
- ACM Backup/Restore Managed cluster restore should automatically import non hive clusters
Why is this important?
- When restoring managed clusters on a new Hub, if clusters were not created with the hive api, the managed clusters shows as Pending Import. This means that, in a DR situation, when the hub goes down and a new one is setup, RTO is high - since the user must take each non hive managed cluster and reimport. It also requires the user to have the cluster connection credentials for all these clusters, which is error prone and can result in data leaks
Related to this https://coreos.slack.com/archives/C0282HW2YHZ/p1649794193133599
Scenarios
- The user manages hive and non hive clusters
- Backs up data
- Hub goes down, data moved to a new hub
- The new hub automatically connects to ALL clusters ( hive and on hive )
Acceptance Criteria
- CI - MUST be running successfully with tests automated
- Release Technical Enablement - Provide necessary release enablement details and documents.
- When managed clusters are restored on a new hub, non hive clusters should be automatically connected with the new hub
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>