How to categorize this issue?
/area control-plane
/kind enhancement
/priority 3
What would you like to be added:
I'd like to ask for a small symmetry improvement between the two rollout strategies. Right now the InPlaceUpdate path applies two Node labels that are super useful for any drain-aware downstream component:
node.machine.sapcloud.io/candidate-for-update: set on every Node that belongs to an outdated MachineSet at the start of a rollout. Effectively: "this Node will be replaced at some point during this rollout".node.machine.sapcloud.io/selected-for-update: set on the specific Node that is being drained right now.
These labels are great. They give downstream operators a clear, declarative signal: a rollout is in progress, here is the full set of affected Nodes, and here is the one currently being worked on. The labels are even already defined as named constants in the API package, so there's nothing internal or private about them.
The catch is that they are only emitted by the in-place path. On the RollingUpdate (surge) strategy, neither label is set. That means anyone who wants the same drain-awareness on the rolling path has to infer a rollout from indirect signals like pool-hash skew, image/kubelet-version heterogeneity inside a pool, or by reaching into the seed and watching Machine deletion timestamps. All of these work, but they're brittle and strategy-specific. Each downstream ends up reimplementing the same inference, slightly differently, with its own failure modes.
The ask
Emit the same two labels in the RollingUpdate path, with the same semantics:
candidate-for-update=true on every Node of an outdated MachineSet, the moment the MachineDeployment determines a rollout is needed.selected-for-update=true on the Node whose Machine has just been picked for deletion in the current batch, set just before drain. Removed when the Machine is gone.
No new API surface, no new constants, no behavioural change beyond the labels.
How to categorize this issue?
/area control-plane
/kind enhancement
/priority 3
What would you like to be added:
I'd like to ask for a small symmetry improvement between the two rollout strategies. Right now the
InPlaceUpdatepath applies two Node labels that are super useful for any drain-aware downstream component:node.machine.sapcloud.io/candidate-for-update: set on every Node that belongs to an outdated MachineSet at the start of a rollout. Effectively: "this Node will be replaced at some point during this rollout".node.machine.sapcloud.io/selected-for-update: set on the specific Node that is being drained right now.These labels are great. They give downstream operators a clear, declarative signal: a rollout is in progress, here is the full set of affected Nodes, and here is the one currently being worked on. The labels are even already defined as named constants in the API package, so there's nothing internal or private about them.
The catch is that they are only emitted by the in-place path. On the
RollingUpdate(surge) strategy, neither label is set. That means anyone who wants the same drain-awareness on the rolling path has to infer a rollout from indirect signals like pool-hash skew, image/kubelet-version heterogeneity inside a pool, or by reaching into the seed and watching Machine deletion timestamps. All of these work, but they're brittle and strategy-specific. Each downstream ends up reimplementing the same inference, slightly differently, with its own failure modes.The ask
Emit the same two labels in the
RollingUpdatepath, with the same semantics:candidate-for-update=trueon every Node of an outdated MachineSet, the moment the MachineDeployment determines a rollout is needed.selected-for-update=trueon the Node whose Machine has just been picked for deletion in the current batch, set just before drain. Removed when the Machine is gone.No new API surface, no new constants, no behavioural change beyond the labels.