Rollout Strategy does not work for MWRS updates, only works for the initial creation

[annelaucg]

Describe the bug
A clear and concise description of what the bug is.
This is my MWRS rollout strategy:

- name: clusterset-placement
      rolloutStrategy:
        type: Progressive
        progressive:
          minSuccessTime: 2m
          progressDeadline: 10m
          maxFailures: 5%
          maxConcurrency: 1

on the initial creation, I can see the minSuccessTime followed and the rollout waits the full 2 mins before it rolls out to the next cluster.

however when I apply the same MWRS with a new image, I can see that the update rolls out to both clusters at the same time and does not wait for one to complete before rolling out.

Initial Creation

annelau@annelau ~ % kc get pods -n samtest --context kind-cluster1
NAME                             READY   STATUS    RESTARTS   AGE
hello-rollout-555b6d77cb-jhvcp   1/1     Running   0          4m4s
hello-rollout-555b6d77cb-qm95p   1/1     Running   0          4m4s
hello-rollout-555b6d77cb-t2rnt   1/1     Running   0          4m4s
hello-rollout-555b6d77cb-th8dw   1/1     Running   0          4m4s
hello-rollout-555b6d77cb-wq7wj   1/1     Running   0          4m4s
annelau@annelau ~ % kc get pods -n samtest --context kind-cluster2
NAME                             READY   STATUS    RESTARTS   AGE
hello-rollout-555b6d77cb-cb8ps   1/1     Running   0          28s
hello-rollout-555b6d77cb-gft9s   1/1     Running   0          28s
hello-rollout-555b6d77cb-kpchc   1/1     Running   0          28s
hello-rollout-555b6d77cb-t8dht   1/1     Running   0          28s
hello-rollout-555b6d77cb-zb4gr   1/1     Running   0          28s

After an update apply:

annelau@annelau~ % kc get pods -n samtest --context kind-cluster1
NAME                             READY   STATUS    RESTARTS   AGE
hello-rollout-555b6d77cb-qm95p   1/1     Running   0          6m36s
hello-rollout-555b6d77cb-t2rnt   1/1     Running   0          6m36s
hello-rollout-555b6d77cb-th8dw   1/1     Running   0          6m36s
hello-rollout-64f9d8b6d6-6f6kl   1/1     Running   0          90s
hello-rollout-64f9d8b6d6-xr275   1/1     Running   0          58s
annelau@annelau~ % kc get pods -n samtest --context kind-cluster2
NAME                             READY   STATUS    RESTARTS   AGE
hello-rollout-555b6d77cb-cb8ps   1/1     Running   0          3m1s
hello-rollout-555b6d77cb-gft9s   1/1     Running   0          3m1s
hello-rollout-555b6d77cb-kpchc   1/1     Running   0          3m1s
hello-rollout-64f9d8b6d6-hvxb4   1/1     Running   0          60s
hello-rollout-64f9d8b6d6-xmjqn   1/1     Running   0          92s

You can see that both clusters are updated at the same time.

To Reproduce
Steps to reproduce the behavior:

1. Create a MWRS with a progressive rolloutStrategy
2. Apply that MWRS (you will see the minSuccessTime and other rules obeyed)
3. Edit the MWRS with a new image or any change
4. Apply that MWRS (you will see that the change is rolled out to both clusters at the same time)

Expected behavior
A clear and concise description of what you expected to happen.

I expect that the same rolloutstrategy defined in the MWRS will be followed during both the update of MWRS>

Environment ie: OCM version, Kubernetes version and provider:
OCM Version: v1.0.0
Client Version: v1.32.3
Kustomize Version: v5.5.0
Server Version: v1.32.2

Additional context
Add any other context about the problem here.

[dosubot]

Hi @annelaucg! I'm Dosu and I’m helping the ocm team.

Your expectation is correct: the documentation and design of OCM's rolloutStrategy (including Progressive) indicate it should control both initial deployments and updates, such as new images or configuration changes, across clusters docs blog. The observed behavior—where progressive rollout only works on initial creation and not on updates—matches what others have reported as a limitation or bug in the MWRS controller #1198.

The MWRS controller code applies rollout logic via a set of reconcilers, especially deployReconciler, but there appears to be an implementation gap: updates may bypass progressive rollout checks and treat changes as "all-at-once" events, rather than respecting minSuccessTime and maxConcurrency controller code.

There are no recent fixes or workarounds documented for this issue. If you need advanced progressive rollout on updates, you may need to monitor the MWRS controller logic or consider custom controller logic as discussed in the referenced issue. If you want to escalate or help resolve this, providing detailed reproduction steps and code pointers (as you have) will be useful for maintainers.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[qiujian16]

cc @haoqing0110

[haoqing0110]

@annelaucg, thanks for reporting this. Let me try to reproduce it locally and find the root cause.

[qiujian16]

/assign @haoqing0110

[haoqing0110]

PR #1207 will fix this issue.