Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Catapult needs a way to provision an imported CaaSP4 cluster #180

Open
HartS opened this issue Apr 17, 2020 · 2 comments
Open

Catapult needs a way to provision an imported CaaSP4 cluster #180

HartS opened this issue Apr 17, 2020 · 2 comments

Comments

@HartS
Copy link
Contributor

HartS commented Apr 17, 2020

When importing a caasp4 cluster, I haven't found a good way to provision things like the clusterroles, clusterrolebindings, storageclass, etc. which are typically provisioned as part of make k8s when using an ECP+caasp4os BACKEND

@viccuad
Copy link
Member

viccuad commented Apr 20, 2020

I think this is out of scope for Catapult.

If you are importing a cluster on ECP with BACKEND=caasp4os KUBECFG=<..> make kubeconfig ,

  • How does Catapult know which project is it importing from?
  • Is it really in ECP? or cloud.suse.de? or which openstack?
  • If you have the openrc and a cloud, why not deploy with Catapult from the beginning?

It gets worse when importing more loosely with BACKEND=imported KUBECFG=<..> make kubeconfig/k8s, the cluster could be wherever and whatever.

How do we add clusterroles? Is the cluster already setup with specific clusterroles, storageclass? If so, do we edit them, or leave them? If we edit them, we might as well just deploy a new cluster.

I think the best we can do when importing clusters is to safely import clusters already deployed with Catapult via BACKEND={caasp4os,eks,gke,aks} make kubeconfig, and run kube-ready-state-check.sh to make sure the imported cluster is sane.
If kube-ready-state-check.sh fails, the imported cluster (that was created our of Catapult) ought to be fixed by hand, there's too many variables per backend.

@HartS
Copy link
Contributor Author

HartS commented Apr 21, 2020

I don't see why this would be out of scope for catapult.

In the case where catapult needs to deploy a new CaaSP4 it's actually doing more than just deploying CaaSP4. It deploys CaaSP4 , then it does things like create a storageclass (OK, this is actually entangled with the CaaSP4 provisioning currently, but we could either document a requirement for a separate NFS or use something like hostpath to establish the persistent storageclass on an existing CaaSP4); catapult also sets up the cap-values configmap with some values which it will need to carry between deployments. I think it does some other things too (installing helm if it doesn't exist, )

If catapult doesn't have the option to provision a CaaSP4 cluster which has just had the bare minimum CaaSP installation, at the very least it should be able to validate that has been provisioned in the way that it expects and provide a list of the things an administrator needs to do so that catapult can take a cluster and deploy scf on it, rather than failing one issue at a time with sometimes confusing errors when the admin hasn't done all the proper setup.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants