Epic Goal

Identify scenarios in a hub active-passive configurations and what are the users steps to have the managed clusters always connected to the active side

Why is this important?

Allow the users to repeatedly and confidently make use of a hub backup - recovery operation

Scenarios

Scenarios:

Case 1

1. Customer has HubA active and HubB passive in  a standard ACM HA-DR scenario https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.9/html/business_continuity/business-cont-overview#disaster-recovery
2. Hub A becomes unavailable ( here to review what situations can get to that and how they are managed during the passive takeover )
3. does a failover to HubB - Hub B becomes active 
4. HubA recovers (lets say it was a network issue and someone fixed the network) - what must be done to ensure it does not cause conflict - managed clusters don't bounce back to hub A

Case 2 ( how to make hub A active after a failover )

Let's assume the user wants to test an active - passive, so he wants to get back to hubA being active after a hub failover to hub B

1. Customer has HubA active and HubB passive in  a standard ACM HA-DR scenario https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.9/html/business_continuity/business-cont-overview#disaster-recovery
2. Hub A becomes unavailable 
3. does a failover to HubB - Hub B becomes active 
4. User wants to bring back hub A and become the active hub - what must be done to ensure it does not cause conflict - managed clusters don't bounce back to hub A

Case 3 - (Active-Active configuration ) require support for multiple hubs managing the same cluster 

Case 4 - Global hub configuration backup / restore : what is the proposed solution for backing up hubs data when they are managed by a global hub. What is the global hub restore approach ?

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.