Implement adoption of k8s clusters

[kylewuolle]

This PR resolves issue #542 by:

1. Renaming ManagedCluster to ClusterDeployment
2. Creation of a new template called adopted cluster that allows creating services via a sveltoscluster for existing k8s clusters not created via 2a

[zerospiel]

@kylewuolle can the PR be split into two different PRs (or at least 2 different commits within the PR): the one with the renaming and the one with the adopted templates feature? Otherwise, there are too many changes to review and each requires attention because one might be either a simple renaming (which is pretty simple to review) or a feature (which requires extra attention)

[kylewuolle]

@kylewuolle can the PR be split into two different PRs (or at least 2 different commits within the PR): the one with the renaming and the one with the adopted templates feature? Otherwise, there are too many changes to review and each requires attention because one might be either a simple renaming (which is pretty simple to review) or a feature (which requires extra attention)

Done!

[zerospiel]

Mostly, minor comments. I have a generic question: so the whole approach is to provide a template with an external (third-party, BYO) cluster, so it could be attached to the HMC but without handling any actions related to the provisioning and its managing, right?

I also have a concern regarding the provider name infrastracture-internal, I am not aware how it should be named in terms of CAPI, I'd consult with other team members regarding it

[kylewuolle]

Mostly, minor comments. I have a generic question: so the whole approach is to provide a template with an external (third-party, BYO) cluster, so it could be attached to the HMC but without handling any actions related to the provisioning and its managing, right?
That's right so the idea is essentially to be able to create a sveltos cluster to deploy beachhead services and also allow for observability etc of existing k8s clusters which 2a does not provision or manage.

I also have a concern regarding the provider name infrastracture-internal, I am not aware how it should be named in terms of CAPI, I'd consult with other team members regarding it

Open to ideas for sure. I wanted to stay away from infrastructure-hmc since we'll be renaming that so not sure what else would be appropriate.

[zerospiel]

LGTM, I'd wait for the ideas regarding the infrastructure-internal provider name and maybe update the ClusterDeployment aliases to something like cldeploy (the only alias, cld might potentially interfere with other resources one day) but it is a personal preference (clusterd sounds similar to a cluster daemon)

[eromanova]

Mostly minor comments.
Ideally, before creating the ClusterDeployment with the adopted template, we should ensure that Sveltos is ready (because the template includes objects from the Sveltos API). For example, consider the template as invalid if the Sveltos is not ready yet (by the template controller) and then validate it in the webhook on a clusterdeployment creation, similarly to the current approach with the providers' readiness. But sveltos is not a provider and we probably should have a separate annotation for that and implement a separate logic in the controller. Anyway, It’s worth gathering more opinions on this approach.