crd-bumper: A tool to bump a repo's CRD versions.

[roehrich-hpe]

See Kubebuilder's "Tutorial: Multi-Version API"
(https://book.kubebuilder.io/multiversion-tutorial/tutorial) for a description of the mechanism.

This tool implements the hub-and-spoke model of CRD versioning. See Kubebuilder's "Hubs, spokes, and other wheel metaphors" (https://book.kubebuilder.io/multiversion-tutorial/conversion-concepts) for a description of the model.

[bdevcich]

The instructions above assume you're in this directory, so do we need to add the cloned folders to .gitignore?

[roehrich-hpe]

Now the tool does the clone for you, and clones it under workingspace/lustre-fs-operator (in this case). That dir is already covered by .gitignore.

[bdevcich]

I'd recommend running all this python code through black:

$ black --check .
would reformat /Users/blakedevcich/src/rabbit/nnf-deploy/tools/crd-bumper/pkg/copyright.py
would reformat /Users/blakedevcich/src/rabbit/nnf-deploy/tools/crd-bumper/pkg/fileutil.py
would reformat /Users/blakedevcich/src/rabbit/nnf-deploy/tools/crd-bumper/pkg/project.py
would reformat /Users/blakedevcich/src/rabbit/nnf-deploy/tools/crd-bumper/pkg/make_cmd.py
would reformat /Users/blakedevcich/src/rabbit/nnf-deploy/tools/crd-bumper/crd-bumper.py
would reformat /Users/blakedevcich/src/rabbit/nnf-deploy/tools/crd-bumper/pkg/controllers.py
would reformat /Users/blakedevcich/src/rabbit/nnf-deploy/tools/crd-bumper/pkg/git_cli.py
would reformat /Users/blakedevcich/src/rabbit/nnf-deploy/tools/crd-bumper/pkg/create_apis.py
would reformat /Users/blakedevcich/src/rabbit/nnf-deploy/tools/crd-bumper/pkg/webhooks.py
would reformat /Users/blakedevcich/src/rabbit/nnf-deploy/tools/crd-bumper/pkg/conversion_gen.py

Oh no! 💥 💔 💥
10 files would be reformatted, 1 file would be left unchanged.

[roehrich-hpe]

I'd recommend running all this python code through black:

Done.

[ajfloeder]

How does versioned CRDs change the development process from the case where CRDs can be modified without regard version.
Would I be responsible for knowing I'm about to create a new version of the CRD and use this tool before I implement that new version? OR
Would I develop my new CRD completely, then use this tool to bump the version and create the conversion routines?

[roehrich-hpe]

How does versioned CRDs change the development process from the case where CRDs can be modified without regard version. Would I be responsible for knowing I'm about to create a new version of the CRD and use this tool before I implement that new version? OR Would I develop my new CRD completely, then use this tool to bump the version and create the conversion routines?

In DWS and lustre-fs-operator, we created a second API version 16 months ago. Think about how you have been making changes in those repos since then. When you make a change there, you're changing the most current API version (the hub), and letting 'make test' tell you when you need to add a conversion routine to the previous version (the spoke).

I think we do need to document some guidelines, some best practices. Just thinking about our experiences in writing the conversion routines, and what sorts of things add to the complexity of those routines, it seems best to not rename a field, or change the type of a field. That's just one example.

[roehrich-hpe]

How does versioned CRDs change the development process from the case where CRDs can be modified without regard version. Would I be responsible for knowing I'm about to create a new version of the CRD and use this tool before I implement that new version? OR Would I develop my new CRD completely, then use this tool to bump the version and create the conversion routines?

In DWS and lustre-fs-operator, we created a second API version 16 months ago. Think about how you have been making changes in those repos since then. When you make a change there, you're changing the most current API version (the hub), and letting 'make test' tell you when you need to add a conversion routine to the previous version (the spoke).

I think we do need to document some guidelines, some best practices. Just thinking about our experiences in writing the conversion routines, and what sorts of things add to the complexity of those routines, it seems best to not rename a field, or change the type of a field. That's just one example.

Another example: if the field has a +kubebuilder:default, then be very careful about changing the default value. If the hub and the spoke have different defaults, give some consideration about how to handle the conversion routine.

[bdevcich]

Another example: if the field has a +kubebuilder:default, then be very careful about changing the default value. If the hub and the spoke have different defaults, give some consideration about how to handle the conversion routine.

I could see this sort of thing come up when changing defaults in Nnf*Profile resources. Especially with tweaking data movement.

[bdevcich]

Bravo! 👏