Epic Goal

Allow for moving management of a cluster previously installed using the infrastructure operator to a different hub. This move should not impact the available features for this cluster.

Why is this important?

Customers with many managed clusters will sometimes need to move the managed clusters under new hubs to load balance the management workload. Currently this can be done by importing the cluster [1] into the target hub (as if it had been installed from elsewhere), but this limits the use of certain features. Specifically previously installed nodes cannot be unbound and reused. Additionally, there are risks associated with creating BareMetalHosts in a new hub that will need to be mitigated.

Scenarios

1. All resources related to a cluster can be created on a hub to continue to manage this cluster as if it had been installed on this hub without adverse affect to the managed cluster. These resources include: ClusterDeployment, AgentClusterInstall, InfraEnv, NMStateConfig, Agent, AgentClassification, BareMetalHost.
2. The import process without additional install-time resources documented in [1] must continue to function.

Acceptance Criteria

Existing e2e tests continue to pass and the scenarios described work as expected.

Dependencies (internal and external)

1. TBD

Previous Work (Optional):

Document outlining issues and potential solutions to several day2/DR scenarios: https://docs.google.com/document/d/1g77MDYOsULHoTWtjjpr7P5_9L4Fsurn0ZUJHCjQXC1Q/edit?usp=sharing

Document describing a potential method for allowing Agent CRs to be created using the kube API: https://docs.google.com/document/d/15IcAU-9V-WPINhtpAG_-eDioHOLS-ELS9hcU50jeWQM/edit?usp=sharing

Open questions:

1. Do we have enough information in the agent CR to recreate a working host record? If not how do we handle this?

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.

References

[1] https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.11/html/clusters/cluster_mce_overview#import-ocp-cluster