Remove experimentalRetryJoin

[killianmuldoon]

experimentalRetryJoin is deprecated as of CAPI release 1.2. Removal is expected to happen in release 1.3 - but before proceeding we should have high confidence that CAPI + Kubeadm are capable today of solving the problem that experimentalRetryJoin was designed to fix.

In order to increase confidence in the removal we should:

1. Ask providers which, if any, are still using experimentalRetryJoin, to what extent, and to solve what problem.
2. Figure out a testing strategy for providers that would trigger the problem experimentalRetryJoin was designed to fix.
3. Ensure these tests are passing and we have high confidence in the current retryJoin behaviour of Kubeadm.

Once we're confident that we can proceed with removal we need to:

1. Remove the field from the bootstrap KubeadmConfig types + regenerate CRDs
2. Stop embedding the kubeadm-bootsrap-script in bootstrap/kubeadm/internal/cloudinit/cloudinit.go
3. Update cloudinit.go, removing functions and variables related to the embedded script e.g. generateBootstrapScript, kubeadmBootstrapScript
4. Remove the KubeadmBootstrap script
5. Add a note to the migration guide that the

/area bootstrap

[sbueringer]

In my opinion we should never remove a field from a v1beta1 apiVersion without an apiVersion bump as it's a breaking change to v1beta1 otherwise.

[killianmuldoon]

In my opinion we should never remove a field from a v1beta1 apiVersion without an apiVersion bump as it's a breaking change to v1beta1 otherwise.

Good point, but I suppose that doesn't necessarily preclude us from changing the behaviour. It's not exactly a feature gate, but the field is prefixed with experimental

[sbueringer]

So we would keep the field but disable its behavior? I think that's a very dangerous precedent and ~ the same as dropping the field.

[killianmuldoon]

So we would keep the field but disable its behavior? I think that's a very dangerous precedent and ~ the same as dropping the field.

This is done regularly for experimental features as I understand it. The key question is whether we consider this experimental or not given the prefix. I think the most important thing here is whether the actual behaviour is fixed rather than the API fields and behaviour though.

[killianmuldoon]

Maybe an alternative path to deprecating this is to add a feature flag and a binary flag to enable this behaviour while deprecating and eventually removing the experimental API field. This would bring the way we enable the feature in line with our other experimental features like ClusterClass and MachinePools.

[vincepri]

/kind api-change

As mentioned above, we need to deprecate now (just a comment on the field would suffice) + remove in the next API version

[vincepri]

/triage accepted

[fabriziopandini]

/milestone v1.3

we should get this done before the release