Consolidate cluster-stacks folder structure

[paulphys]

Right now we have two cluster-stacks, alpha and scs, it is not clear which one is the mainly maintained cluster-stack. Therefore we should either remove one of them or give it a name that describes the purpose of each cluster-stacks, e.g. stable/unstable/dev.

• [x] #93
• [x] #101

[mxmxchere]

We can also place an additional explanation file in the folder to explain the purpose and the guarantees of stable and unstable cluster-stacks.

For example we could guarantee that specific variables will be maintained or warn that they might change in case of an unstable clusterstack.

[jschoone]

Hi @paulphys, thanks for this issues. The scs Cluster Stack was the first try to represent KaaS v1 stuff in KaaS v2. alpha was the try to use the learnings from scs and clean it up. But I think we can still do better. My suggestion would be to delete both and create a new Cluster Stack which will represent what we want to achieve. Some problems are e.g. we need to add the Kubernetes version on various places. With Cluster Stacks approach this only needs to be in csctl.yaml with which csctl makes the rest.

[mxmxchere]

In todays container call i learned that a clusterstack is the sum of all node-definitions, cluster-classes and cluster-addons over all k8s-versions over all providers that share the same clusterstack name.

Therefore i think the following folder-structure would better reflect this relation:

clusterstacks/
└── <cluster_stack_name>/
    └── <provider_name>/
        └── <k8s_major_minor_version>/

instead of

providers/
└── <provider_name>/
    └── <cluster_stack_name>/
        └── <k8s_major_minor_version>/

actual folder names:

cluster-stacks/
└── scs/
    └── README.md/   // describes features, goals, guarantees, tests
    └── openstack/
        └── 1-27/
        └── 1-28/
        └── 1-29/
    └── docker/
        └── 1-27/
        └── 1-28/
        └── 1-29/

Regarding CSO and CSPO this change would not do any harm, as the operators do not care about the git-state (only reading the GitHub releases) and in the release itself there are only assets of the most deeply nested path.

The question is if csctl would have issues with this change. Maybe @janiskemper or @michal-gubricky know?

[mxmxchere]

I have another question:

does the most deeply nested folder (the kubernetes version) that contains cluster-class, cluster-addon and node-image have a name?

providers/
└── <provider_name>/
    └── <cluster_stack_name>/
        └── <k8s_major_minor_version>/  how is this kind of folder called?

[janiskemper]

@mxmxchere you are 100% correct and there wouldn't be any issues. I strongly recommend to not choose "alpha" as cluster stack name in the future, because "alpha" should be rather "an alpha state of cluster stack xyz", so like a release channel stable, alpha, beta.

The cluster stack names should ideally be independent of both "scs" and anything like "stable", "alpha", etc. to not confuse this.

For example, what do we do if we have beta releases of the "alpha" cluster stack? And what if there is an "scs" cluster stack, but now we want to do a second one? Is that called "scs2" then?

[jschoone]

@mxmxchere you are 100% correct and there wouldn't be any issues. I strongly recommend to not choose "alpha" as cluster stack name in the future, because "alpha" should be rather "an alpha state of cluster stack xyz", so like a release channel stable, alpha, beta.

The cluster stack names should ideally be independent of both "scs" and anything like "stable", "alpha", etc. to not confuse this.

For example, what do we do if we have beta releases of the "alpha" cluster stack? And what if there is an "scs" cluster stack, but now we want to do a second one? Is that called "scs2" then?

Hi @janiskemper I chose the name alpha on purpose for exactly the reason that this is probably not stable yet since we still working on good cluster stacks. That's why I suggested to delete alpha and scs again (see https://github.com/SovereignCloudStack/cluster-stacks/issues/56#issuecomment-2048914254) and put our learnings into new Cluster Stacks.