chore: Version CRD and AirflowClusterConfig#581
Conversation
NickLarsenNZ
left a comment
There was a problem hiding this comment.
Just left a couple of comments.
Co-authored-by: Nick <10092581+NickLarsenNZ@users.noreply.github.com>
There was a problem hiding this comment.
LGTM - ran a few tests and verified the CRD has not changed at all. As a general comment (i.e. not blocking this PR), I would like to have an explanation somewhere (probably here) that illustrates what the code will look like when we have multiple versions (see for instance the places I've highlighted with "see general review comment"). Will that just be a matter of extending the annotation? Will the operator code get more "cluttered"?
Plus: thanks for the clean up! (renaming constants, sorting/grouping imports etc.) 👍
What the macro expands to is explained in great detail in the doc comments. I however noticed, that the docs don't mention an example with two or more versions. I will add that.
Yes, new versions can simply be introduced by adding it to the the list of versions in the attribute macro. Eg: #[versioned(
version(name = "v1alpha1"),
version(name = "v1beta1")
)]
pub mod versioned {}
Hopefully not. The current plan is to only use the latest version in code, eg: If we would to update the CRD from v1alpha1 to v1beta1, the code will use v1beta1 (where currently v1alpha1 is used) and will additionally provide a conversion from v1alpha1 to v1beta1 (ideally also the other way around, but different discussion).
Sure thing :) |
Part of stackabletech/issues#642
This PR adds versioning to the Airflow CRD and cluster config. It doesn't introduce any new version or updates the CRD in any way. It currently emits the same
crd.yamlwhich is the correct expected behaviour.Tip
It is recommended to look at this PR on a commit-by-commit basis to better understand the individual steps taken.