Cluster provisioning without cluster installation about hive

[dgoodwin]

In general we refer to this as "cluster adoption". We're getting closer to being able to support this, the problem right now is that if you create a ClusterDeployment, Hive will immediately try to provision it. We have changes underway that should open the door for this, specifically a flag on your ClusterDeployment that indicates it's already installed.

For (1): To do this you would need to provide a secret to Hive with the admin kubeconfig for the cluster. All hive communication with the cluster is then via standard Kube API.

For 2: You'd need to inform Hive of the admin kubeconfig, but otherwise for the cluster itself, I don't think anything is required.

For 3: In theory yes, but then if SRE changes their configuration, that change would not roll out to your cluster. If there's an expectation that those clusters are under some form of on-going management, they should probably remain in the Hive system.

We may have quite a bit of work to do to control what Hive tries to manage and what it doesn't. We'll probably want to go through each thing under active management, figure out if it's desired or not, and then make sure it can be safely disabled on a ClusterDeployment.

Quick list off the top of my head:

1. MachineSets and their sizes.
2. Control plane certificates (via letsencrypt in Hive prod)
3. Ingress Configuration
4. Identity Providers

SyncSets generally work off labels, configuration goes to the ClusterDeployments with labels that match the SyncSet, so you'd need to coordinate those with SRE who control their SyncSet config so that your ClusterDeployment labels will match and get you the config you want in-cluster.

[gregsheremeta]

adoption is now available