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
Upstream implementation of ClusterClass does not include any versioning features. As classes are simply Kubernetes objects, there's no native way of creating new versions of an existing topology template, other than creating a completely new resource with no link to the previous one. To simplify user interaction with templates and favor the provisioning of clusters via ClusterClass, we need to support a versioning mechanism that provides a way to maintain variations of the same template and apply different iterations of it to downstream clusters accordingly.
From a Rancher perspective we can treat ClusterClass resources with a given resource name, same way we do with clusters.management.cattle.io resources, which are generated with a random name and then shown in Rancher Dashboard with a DisplayName which is part of the specification. In the case of versioning, we can accomplish this with two annotations:
This will mean that, when users create a new ClusterClass object:
Automatically assign the provided name to cluster-api.cattle.io/display-name and set version accordingly.
Support new version creation: new ClusterClass object will be created with the same display name and increased version. This could probably be user provided or automatically increased (at least we should track what type of semver upgrade it is: major, minor, patch).
To simplify management of ClusterClass resources on Rancher, we could apply a filter so that only classes with both annotations are shown in the UI. Users will need to add them to existing class objects (perhaps we could also create some kind of import mechanism that automatically adds annotations?).
The text was updated successfully, but these errors were encountered:
This is issue is part of the epic #387.
Description
Upstream implementation of
ClusterClass
does not include any versioning features. As classes are simply Kubernetes objects, there's no native way of creating new versions of an existing topology template, other than creating a completely new resource with no link to the previous one. To simplify user interaction with templates and favor the provisioning of clusters viaClusterClass
, we need to support a versioning mechanism that provides a way to maintain variations of the same template and apply different iterations of it to downstream clusters accordingly.Features
You can read the proposal https://docs.google.com/document/d/1d20K5DSHvrtY_bQWVzT1gf_lza7pgI8wZfFXXUX3p4k/edit?usp=sharing where you can find detailed information on the proposed feature.
From a Rancher perspective we can treat
ClusterClass
resources with a given resource name, same way we do withclusters.management.cattle.io
resources, which are generated with a random name and then shown in Rancher Dashboard with aDisplayName
which is part of the specification. In the case of versioning, we can accomplish this with two annotations:This will mean that, when users create a new
ClusterClass
object:cluster-api.cattle.io/display-name
and set version accordingly.ClusterClass
object will be created with the same display name and increased version. This could probably be user provided or automatically increased (at least we should track what type of semver upgrade it is: major, minor, patch).To simplify management of
ClusterClass
resources on Rancher, we could apply a filter so that only classes with both annotations are shown in the UI. Users will need to add them to existing class objects (perhaps we could also create some kind of import mechanism that automatically adds annotations?).The text was updated successfully, but these errors were encountered: