Rollout does not follow canary strategy when .spec.selector.matchLabel is changed

[ayush-rathore-zepto]

Checklist:

• I've included steps to reproduce the bug.
• I've included the version of argo rollouts.

Describe the bug
When changing the .spec.selector.matchLabel in a rollout resource, the steps described in .spec.strategy.canary.steps is not followed in the traffic migration to the new replicaSet

To Reproduce

Create a

Create a rollout with following spec

spec:
  replicas: 2
  selector:
    matchLabels:
      app.kubernetes.io/name: app
      app.kubernetes.io/team: old-team
  strategy:
    canary:
      dynamicStableScale: true
      pingPong:
        pingService: root
        pongService: canary
      steps:
      - setCanaryScale:
          weight: 25
      - setWeight: 0
      - pause:
          duration: 60
      - setCanaryScale:
          weight: 30
      - setWeight: 30
      - pause:
          duration: 120
      - setCanaryScale:
          weight: 60
      - setWeight: 70
      - pause:
          duration: 90
      trafficRouting:
        alb:
          ingresses:
          - private-http
          rootService:root
          servicePort: 80

Change the value of .spec.selector.matchLabel.[app.kubernetes.io/team] from old-team to new-team

Expected behavior

The new replicaSet should be created, the reset of revision history to revision 1 is expected, but the traffic migration to the new service must be done using the steps described in .spec.strategy.canary.steps in the rollout

Actual behavior

The traffic is migrated all at once to the new replicaSet, immediately, resulting in downtime as all pods in the new replicaSet are only initializing

Version

v1.7.2

Message from the maintainers:

Impacted by this bug? Give it a 👍. We prioritize the issues with the most 👍.

[ayush-rathore-zepto]

Is this is a known/intended behaviour, Is there a workaround to this?

[zachaller]

Yea that field should actually probably be immutable to match the Deployment kinds behavior, #2105 this would be a breaking change in behavior though so we would need to think about how to handle that

[zachaller]

fixed in #4084