Support HotUpdate of Machines for Provider specific Hot-Updateable fields on the MachineClass #1060
Description
How to categorize this issue?
/area usability
/kind enhancement
/priority 3
What would you like to be added:
Today, gardener generates new MachineClasses whenever the ProviderConfig is changed. Taking an example from https://github.com/gardener/gardener-extension-provider-aws/blob/master/docs/usage/usage.md#workerconfig, if the volume.iops or volume.throughput is changed, the gardener-extension-provider-aws will generate fresh MachineClasses. The MCM then triggers a re-rollout of the fresh Machines corresponding to these new MachineClasses. We would like to avoid this and support hot-update of hot-updateable properties for each provider by leveraging a proposed Driver.UpdateMachine/HotUpdateMachine. Since, fields are provider specific, the details of which fields are hot-updateable and which fields are not should be covered in provider specific issues.
This is a tracking backlog in the MCM to keep track of hot-update support in Machines for individual providers
- AWS
- Azure
- GCP
- OpenStack
- AiCloud
Why is this needed:
Needed to avoid un-necessary and spurious Machine->Instance rollouts when hot-updateable provider specific fields are changed