Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ClusterClass Operations] Add version control to ClusterClass #641

Open
2 tasks
salasberryfin opened this issue Aug 6, 2024 · 0 comments
Open
2 tasks

Comments

@salasberryfin
Copy link
Contributor

salasberryfin commented Aug 6, 2024

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 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.

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 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:

cluster-api.cattle.io/display-name
cluster-api.cattle.io/version

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?).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

1 participant