Skip to content
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

applying changes to machineSpec in MachineSet are not handled. #259

Closed
jpweber opened this issue May 7, 2019 · 2 comments
Closed

applying changes to machineSpec in MachineSet are not handled. #259

jpweber opened this issue May 7, 2019 · 2 comments

Comments

@jpweber
Copy link
Contributor

jpweber commented May 7, 2019

After a machineSet manifest has been applied and nodes are up and running, if one modifies that file within machineSpec. for example, changing numCPUs: 2 to numCPUs: 4 then kubectl apply -f machineset.yaml, no changes occur and there are not any logs about any updates or modifies.

We should probably be able to handle changes to machineSpec, but it does bring up another question of what is the appropriate action to solve those change. Modify in place, launch new node with new settings and delete old node etc.

@ncdc
Copy link
Contributor

ncdc commented May 10, 2019

I am checking to see if this is documented, but we strongly encourage treating everything as immutable infrastructure. If you want to change a machine characteristic, you can create a new machine with the desired changes and then delete the old one. This is handled by MachineDeployments for you - they manage multiple revisions of MachineSets in response to changes you make to a MachineDeployment.

Also worth noting, MachineSet is owned by the cluster-api repo and any behavioral changes to it need to be filed there instead of here. We may want to consider adding some validation to disallow changes to machineSet.spec.template, but again that should be filed in cluster-api, not here.

@jpweber can we close this?

@jpweber
Copy link
Contributor Author

jpweber commented May 10, 2019

@ncdc yup that all makes sense. I think validation of some kind to provide feedback is a good idea so it doesn't just fail silently. Closing.

@jpweber jpweber closed this as completed May 10, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants