User Story
As a developer I would like to have a possibility to modify preKubeadmCommands during KCP update for maintaining compatibility with new images.
Detailed Description
Situation can occur if we need to do something different due to new versions of the kubernetes binaries (kubeadm, kubelet, kubelet) that are baked into a new image.
E.g change a load balancer configuration, call another sysctl to start a new service or something else that was moved or renamed.
/kind feature
I believe the situation would be the same with postKubeadmCommands and files.
/milestone Next
As discussed in the community meeting today, I believe we started with complete immutability, and have been opening up fields to mutability as the need arises. We typically have had to write logic specific to each field (e.g. to sync data into the kubeadm configmap in the workload cluster). But for pre/postKubeadmCommands and files, those likely wouldn't require any syncing.
I think I'm ok allowing these specific fields to be mutated. Anyone else want to weigh in?
cc @detiber
During the meeting, you were mentioning an issue with rollback. What would be the strategy for rollback then ? I would expect the commands would be related to the image we use, so they would need to be in sync.
We don't actually support any rollbacks in KCP, so never mind about what I said in the meeting 馃槃. Whatever is in the KCP spec must be valid whenever creating a new control plane machine.
Hi there! Are there any updates regarding this ? @ncdc and @detiber ? thank you!
/help
/good-first-issue
@ncdc:
This request has been marked as suitable for new contributors.
Please ensure the request meets the requirements listed here.
If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-good-first-issue command.
In response to this:
/help
/good-first-issue
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.
I'm a +1 to allowing mutability for the PreKubeadmCommands and PostKubeadmCommands fields.
/assign
Just a note that we would need it for files too. It is the same use-case.
Most helpful comment
As discussed in the community meeting today, I believe we started with complete immutability, and have been opening up fields to mutability as the need arises. We typically have had to write logic specific to each field (e.g. to sync data into the kubeadm configmap in the workload cluster). But for pre/postKubeadmCommands and files, those likely wouldn't require any syncing.
I think I'm ok allowing these specific fields to be mutated. Anyone else want to weigh in?