I don't think the D->RS abstraction applies to what you are asking for because Deployments manage upgrades for ReplicaSets whereas DaemonSets manage their own upgrades.

This issue sounds like an A/B deployment that cares about topology. I don't think a new controller type is needed. We may be able to specify this mapping between a specific DS version x node version in the existing DaemonSetSpec. And of course DS history is a requirement.

Yeah this sounds like it's what we called step 2 of daemonsets updates - as kargakis notes that will be part of daemon sets itself and the hope was to address it in 1.7

Related: #6086

@piosz My github notifications go to /dev/null, so please notify me out of github if you'd like me to look at something.

@smarterclayton Is "step 2" documented somewhere?

Right now, changing the node selector or other scheduling constraints in the pod template affects all pods of the DaemonSet.

If we only wanted the new constraints to affect updated pods, I believe that would be a change in semantics. That may be fine, but we'd need to think it through.

If we do that, I believe the original passive update policy would enable DaemonSet updates to be driven by either destructive node updates (delete and add node) or in-place node updates that also update node labels.

Right now, changing the node selector or other scheduling constraints in the pod template affects all pods of the DaemonSet.

Just to be clear, every update in the pod template will affect all pods.

If we only wanted the new constraints to affect updated pods, I believe that would be a change in semantics. That may be fine, but we'd need to think it through.

I don't think this is any different from enabling A/B Deployments but I haven't thought out yet the implications of an updated node selector between versions.

If we do that, I believe the original passive update policy would enable DaemonSet updates to be driven by either destructive node updates (delete and add node) or in-place node updates that also update node labels.

This is possible today because the DS is reconciled on any of these events.

Step 2 was in the daemonset upgrade proposal - we punted the bulk of the issue to 1.7 and need to amend the proposal to cover the issues

@bgrant0607 ack
@Kargakis @smarterclayton my intent was to not suggest any solution but only to describe our use case, which seems to be pretty common. I added some example of the solution to show that it's a solvable problem, but I'm not devoted to it.

I think that for OnDelete to be a truly passive strategy ("spin up the same pod that got killed on a node"), we need this issue fixed.

I can imagine this being a mapping of ControllerRevisions to NodeSelectors.

There are some examples in #23233 (add-on umbrella issue).

Sometimes node-level orchestration, such as applying node labels and/or taints, is necessary in conjunction with this. The labels represent properties such as the kubelet release version, features enabled, OS-level initialization, removal of static pod manifests, etc. It might sometimes be necessary to drain nodes prior to update (which effectively happens in the case of destructive node upgrades).

If a security patch or other critical fix were necessary, an administrator might need to roll out a new release of a daemon for a particular set of nodes. I do not want to create any controllers with multiple pod templates, however.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

/remove-lifecycle stale

At minimum, the pattern of using node selectors to coordinate DaemonSet upgrade with node upgrades should be documented.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

/remove-lifecycle stale