Epic Goal

In a hub disaster recovery situation, if the initial hub comes back to life unexpectedly, after the managed clusters were moved to the new hub, the clusters are bouncing back to the initial hub.

Why is this important?

ODF team has a situation where the primary hub is recovered unexpectedly and managed clusters are moved back to the new hub.

We can fix this by adding the import.open-cluster-management.io/disable-auto-import annotation on the primary hub, then run the restore operation on hub b again to recover the managed clusters.

This workaround seems to not work for managed applications

This is the discussion thread

https://redhat-internal.slack.com/archives/C0282HW2YHZ/p1737060204109369?thread_ts=1736163889.894019&cid=C0282HW2YHZ

Scenarios

HubA goes down unexpectedly and comes back to life after a new hub has restored the managed clusters.

Acceptance Criteria

HubA should not try to recover the managed clusters after coming back to life

Dependencies (internal and external)

1. ...

Previous Work (Optional):

1. use import.open-cluster-management.io/disable-auto-import: '' annotation to stop the clusters from being imported back. But it's too late to add this label - the hub goes down uncontrolled 

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.