You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What those have in common and what @paulphys@chess-knight and @mxmxchere have identified as a key-issue is an "artificial" dependency between the cluster-class and the kubernetes version.
Clusterclass is meant to be a template for Cluster-API and cluster-api-provider-openstack resources supporting multiple kubernetes versions. The kubernetes version therefore resides in the cluster-resource and not in the cluster-class.
We should stop putting the kubernetes version inside the ClusterClass name. If we do that, we have the problem that the cso will no longer work.
How many cluster-classes?
One per provider, version stays the same, version is increased on demand not with each k8s version.
Clusterclasses (very few, changed rarely):
cluster-class-openstack-v1 (immutable, no renovate (of course)
cluster-class-openstack-v2
cluster-class-metal3-v1
Cluster-Addons (one per release+k8s combination):
cluster-addon-openstack-v1.27
cluster-addon-openstack-v1.28
cluster-addon-openstack-v1.29
-> Change CSO-behaviour to read only clusterstackname from cluster.spec.topology.class and to read k8s version from cluster.spec.topology.version
Wishlist for the endresult:
documentation page (One Page version, parsed out of each cluster-class?)
tested clusterstacks (latest cluster-class version with 4 latest addons (k8s-version))
renovate/dependabot updating stack-components
The text was updated successfully, but these errors were encountered:
paulphys
changed the title
Make this repo managable
Make this repo manageable
Jun 13, 2024
paulphys
added
Container
Issues or pull requests relevant for Team 2: Container Infra and Tooling
epic
Issues that are spread across multiple sprints
labels
Jun 13, 2024
We already noticed that there is an issue with the structure of this repo in:
What those have in common and what @paulphys @chess-knight and @mxmxchere have identified as a key-issue is an "artificial" dependency between the cluster-class and the kubernetes version.
Clusterclass is meant to be a template for Cluster-API and cluster-api-provider-openstack resources supporting multiple kubernetes versions. The kubernetes version therefore resides in the cluster-resource and not in the cluster-class.
We should stop putting the kubernetes version inside the ClusterClass name. If we do that, we have the problem that the cso will no longer work.
How many cluster-classes?
One per provider, version stays the same, version is increased on demand not with each k8s version.
Clusterclasses (very few, changed rarely):
Cluster-Addons (one per release+k8s combination):
-> Change CSO-behaviour to read only clusterstackname from
cluster.spec.topology.class
and to read k8s version fromcluster.spec.topology.version
Wishlist for the endresult:
The text was updated successfully, but these errors were encountered: