-
Notifications
You must be signed in to change notification settings - Fork 578
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
Trigger machine pool instance refresh also on user data change (unless it's only the bootstrap token) #4245
Trigger machine pool instance refresh also on user data change (unless it's only the bootstrap token) #4245
Conversation
…s it's only the bootstrap token)
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Hi @AndiDog. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
If CAPI introduced a sort of checksum into the bootstrap secret, we could get rid of the complicated diffing code and thereby support any format (cloud-init, ignition). Since I'm anyway working on CAPI so that it reconciles the secret immediately, I will consider that. For now, let's focus this PR review on the idea of triggering an instance refresh in case of relevant changes. |
As discussed in CAPA office hours, this is probably similar to #4195: the parent config (for me: |
I did some followup of my own from the CAPA office hours...
I lack historical context, but I did a tiny bit of digging as we're also interested in making MachinePools better, and it looks like the bootstrap data being mutable and shared were understood in the original proposal: https://github.com/kubernetes-sigs/cluster-api/blob/main/docs/proposals/20190919-machinepool-api.md
kubernetes-sigs/cluster-api#5294 looks like it was tracking work at improving this code area back in 2020-2021, but failed to move forward. Based on all that, it seems like using the WDYT? |
I'll try and discuss this more generically in CAPI office hours. Let's pause any review of this PR for now. |
This is way too hacky. CAPI should provide a contract so providers can check if there's a change. Let's continue solving this generically in kubernetes-sigs/cluster-api#8858. |
What type of PR is this?
/kind feature
What this PR does / why we need it:
Partial fix for #4071
If a user changes instance bootstrapping-related fields such as
KubeadmConfig.spec.{files,preKubeadmCommands,...}
, new instances should get rolled out. This change ensures triggering an ASG instance refresh if more than only the bootstrap token has changed inside user data (= value of the bootstrap data secret generated by CAPI). This assumes CAPI's cloud-init template as user data format. If that format cannot be parsed, we take the safe route and do not trigger an instance refresh.Once CAPA reconciles, the change does what it should. The problem is that on a change to the
KubeadmConfig
object, for example, reconciliation won't be triggered immediately, but the time until next reconciliation still depends on the bootstrap token refresh interval/TTL. I'm working on fixing that in separate CAPI/CAPA PRs. Therefore, this PR only partially fixes #4071.Checklist:
Release note: