Add notes from old container workshop, so we can reference it.

[garloff]

Signed-off-by: Kurt Garloff kurt@garloff.de

[garloff]

Rendered doc at:
https://github.com/SovereignCloudStack/minutes/blob/feat/cont-ws-20220704/container/20220704-workshop.md

[fynluk]

Hey 👋,
I remember the discussion and think it is important to save the outcome here.

I would like to add/start the discussion about the standardized cluster resource:
Maybe you can remember that we started to build a crd for the scs-cluster resource (https://github.com/23technologies/scs-cluster-crd). It includes some of the parameters we defined.

The goal now should be to implement a controller that watches the scs-cluster resources and convert them to gardener shoots and/or cluster-api clusters.
We started to implement such a controller, and you can also find our outcome in the repo mentioned above. There are two controllers (we need one for gardener and one for cluster-api; You only deploy one of them for your destination mk8s software). The controller watches the scs-cluster resources and converts them to a gardener-shoot/capi-cluster.
The process already works, but so far, the created shoot resources are not well templated (it only templates the k8s version and the name).

Before we would go further with the controller development, I would like to give you a small demo and then we could talk about the next steps (better templating/more variables in the scs-cluster resource/support gridscale/...).

Is this the way we should do it?

[janiskemper]

Thanks Fynn, for sketching how to build the repo with kubebuilder. I also think that this is the way to go, since kubebuilder is used by most projects I know. It is definitely very handy that it creates the whole repo including controller template, API, and CRDs. In general, we are only left to implement the logic.

However, I see one big issue with your approach: You have created ONE SCS controller for Cluster API (and, of course, one for Gardener). I'm not going to talk about the one for Gardener now, as it is not my specialty.

CAPI has always general resources like the Cluster object that you create in the code. However, it has also the provider-specific objects (ProviderCluster, ProviderMachine, etc.). As every provider has its own objects, they should not all be created in just one operator. Otherwise, this operator would have to include all provider-specific code for all possible providers. Therefore, with just this one operator that you sketched, we won't be able to handle different Cluster API providers.

We rather need a "library" to be able to write easily provider-specific SCS operators.

[fynluk]

Hey Janis,
thx for your feedback.
You are completely right, capi (and also gardener) has many custom resources and especially a custom provider config.

That's why I started the discussion, we have to collect all parameters (like we already did) and define custom resources we need (scs-cluster would be the root resource and we definitely need more custom resources like a "standardized" provider config).
Maybe we should talk about the provider config next (that should be one of the hardest topics). We have to find a set of variables that fit to hopefully all providers and then we have to build controllers for them too.

Would you agree @janiskemper @ALL

[janiskemper]

Yes @fynluk I fully agree that we can start with the discussion about these parameters!
I just want to point out that there are two things we have to do:
First thing is to have one standardized API to create clusters on any compatible infrastructure. The second task is to have operators that are actually able to create the necessary resources (e.g. Cluster API provider-specific API objects like HetznerClusteror OpenStackMachine). I would say that we should not have one central operator for Cluster API that is able to handle all different providers.

So the first thing depends more on how to define a standardized API for any infrastructure provider and the second is more about how the architecture of the SCS lifecycle system looks like!

We should continue this topic next week in the meeting.

[garloff]

I really appreciate the discussion and progress!
I believe however that it is happening at the wrong place;
the pull request to merge minutes should have seen a review of the minutes with suggestions and/or approval.
Should we replicate the discussion into an issue that tracks the progress of the PoC for the reference implementation?
Obviously, I would like to merge the old minutes, which I can´t without an approving review :-(

[garloff]

Still need a review to merge these aging minutes.
We should do so IMVHO, so have this as reference and have better chances to avoid going back and rediscussing everything ...