Improve usability of ControlPlane's registrationMethod with Cluster Classes #343
Labels
kind/feature
New feature or request
priority/important-soon
Must be staffed and worked on either currently, or very soon, ideally in time for the next release.
triage/accepted
Indicates an issue or PR is ready to be actively worked on.
Describe the solution you'd like:
Due to validation of the
RKE2ControlPlane.spec.registrationMethod
, it is not currently possible to useregistrationMethod: "address"
in ClusterClasses without providing a validregistrationAddress
too.Even with patching this value afterwards, like:
This will fail with:
As the initial RKE2ControlPlane is created with empty
registrationAddress
, before patching.One workaround is to configure the initial registrationMethod to
control-plane-endpoint
or any other default that does not require validation.Then I think one patch should replace both values ad the same time:
I did not test it, but it should technically work.
The drawback of this workaround however, is that initially the RKE2ControlPlane object is created with a different registrationMethod. This could lead to race condition issues where maybe nodes are joining using an unwanted registration method.
It should be fine on the initial cluster creation, assuming the first node ever will be the first control plane node, so there will be nothing to register on yet, and after that (or even before bootstrapping this node), the registrationMethod should be patched to the user defined value.
Could be more tricky however on a control plane rollout or during other upgrade scenarios.
Why do you want this feature:
I want to avoid having to configure a default
registrationMethod
for the real one to be patched later, if this could lead to problems.The text was updated successfully, but these errors were encountered: