✨ Update helm chart and docs to allow for the installation of CP, PCH, statusaddon

[francostellari]

Summary

This PR intends to update helm chart and docs to allow for the installation of CP, PCH, statusaddon

1. Update the make chart to separate the CP and PCH crds from operator.yaml to crds/ folder to guarantee that they are installed before the remaining of the kubeflex chart
2. Update the helm chart to allow for the automatic installation (default off) of ocm, kubestellar, statusaddon Post Create Hooks
3. Update the helm chart to allow for the automatic installation (default off) of user-defined Control Planes
4. Updated the helm chart values.yaml with commented examples of CPs
5. rename postgresql-hook.yaml to simply postgresql.yaml
6. Update the user.md docs to reflect the changes
7. Provide a convenience script to create a suitable kind cluster

All new features are turned off by default.

Related issue(s)

Fixes #213

[MikeSpreitzer]

The command below is a create rather than a patch, right?

[MikeSpreitzer]

This reference is not pinned to a particular version of the referenced content. That makes the behavior of a release of KubeFlex variable, depending on the evolution of something else.

Dependency cycles between repos are bad.

[francostellari]

easy to fix

[MikeSpreitzer]

This is creating several references from the kubeflex repo to the kubestellar repo. Yes, some are commented out, but: (a) they are still there and (b) others are not. Dependency cycles between repos are problematic.

Couldn't this work be put in the kubestellar repo instead? I am thinking of leaving a Helm chart in kubeflex that just installs kubeflex, and introducing a Helm chart in kubestellar that (a) has the kubeflex chart as a dependency (listed in dependencies in Chart.yaml) and (b) adds all the other specifics. Or, perhaps, extend the Helm chart in kubeflex to add facilities for PCHs that install Helm charts and extend OCM --- without even mentioning kubestellar --- and introduce a Helm chart in kubestellar that depends on the kubeflex Helm chart and uses its new facilities.

[ezrasilvera]

Regarding dependency issues KS <--> KF. The source of the issue is due to the desire to leave all options open:

1. Space access
   • If KS controllers get the space(s) config directly as parameters --> KS will not be dependent on KF
   • IF KS controllers retrieve the space config from KF --> KS depends on KF
2. Deploy controllers into a cluster
   • If KS controllers are deployed directly into a cluster --> KS and KF are not dependent
   • IF KS controllers are deployed through PCH --> KF depends on KS

[francostellari]

@ezrasilvera @MikeSpreitzer can you clarify what cycle dependency do you see?
I'm not sure what do you see in this that is not already done by kflex.
I cannot understand #222 (comment)
A comment is not a cycle dependency.

This chart was developed by testing with specific version of kubestellar and ocm. I don't expect any change in this chart once you release ks 0.21, no staggered release. There is also no reference to the kubestellar repo, no dependency.

Additionally, at this moment, I don't think ks repo teaches anybody how to use kflex helm chart either.

This chart is not just for kubestellar user. There may be people that what a k8s CP with ocm in it. Additinal hook support me be added when needed.

Referring to a specific image registry quai.io/kubestellar/helm or quay.io/kubestellar/kubestellar does not create a cycle dependency. It's just using somebody else container image.

[ezrasilvera]

@francostellari I don't understand wat you mean by "A comment is not a cycle dependency." ..
The dependency today is that the code inside the controllers is using KF in order to bring the space(s) information by fetching the ControlPlane information from KF. This means that KS depends on KF

[ezrasilvera]

@francostellari My last comment on dependency is indeed not related to the Helm dependency . So you can mark it as done.
Going through the PR I'm not sure you addressed all of @MikeSpreitzer comments.
@MikeSpreitzer - can you please see @francostellari response at #222 (comment)

[pdettori]

My suggestion to solve the circular dependency issue that has been pointed out by @ezrasilvera and @MikeSpreitzer here is the following:

1. PCH for ocm and kubestellar should be maintained in the KubeStellar repo
2. The KubeFlex chart here should install only KubeFlex without creating control planes
3. The über-chart that does it all should be in the KubeStellar repo. Such chart can import as sub charts the kubeflex chart, the OCM Add-on chart, the OTP chart (each of them is maintained and published in their respective repositories). The über-chart will have also access to the PCHs since they are in the same repo.

[francostellari]

@pdettori , to be clear, there is nothing usable in this PR that should be retained and I can close it, right?

[pdettori]

@francostellari: I think that it is very valuable to have one uber-chart to install it all. Yes, my suggestion was for a new PR to be open in the main kubestellar repo, and to close this one here. Hopefully there is content that can be re-used from here in the new PR.

[francostellari]

Team does not think this is a good idea.

[MikeSpreitzer]

@francostellari, @pdettori: I think that if KubeFlex is successful then we may want to resurrect this PR because it has a couple of good ideas for general use: making it easy to install CPs and PCHs. My problem with the current draft is that those general facilities are not presented as general facilities but rather things that are here to support ks/ks. If the naming and wording (including comments) were generalized to be appropriate for any larger system using kubeflex, then I think this would make sense. To be clear, it would not remove the need for the larger system to have its own Helm chart, but more of the work could be done in this chart from kubeflex.