Closed accepting closed 4 years ago
Hi @accepting. Thanks for your PR.
I'm waiting for a kubernetes-sigs or kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test
on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
Once the patch is verified, the new status will be reflected by the ok-to-test
label.
I understand the commands that are listed here.
/ok-to-test
@accepting This is right. We never set the config value except in the successful case so there is no reason to issue a patch in an error case, but I'm curious why you want this change? Was there a bug you were encountering that this fixes?
@chuckha In our use cases, the bootstrap objects support update. When we try to update a bootstrap object, we found the object was updated even if some error occurs afterwards.
That's interesting. Does an update to the bootstrap object actually modify the cluster?
Yes, with the help of kubeadm phases, we update the control planes/worker nodes' settings by updating their bootstrap objects.
I'm fine merging this and reverting or changing behavior back if we need to start populating the error message.
/approve
[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: accepting, chuckha
The full list of commands accepted by this bot can be found here.
The pull request process is described here
/lgtm
Signed-off-by: JunLi lijun.git@gmail.com
What this PR does / why we need it: There is no need to update KubeadmConfig objects if any error occurs during the reconciliation.