fix!: subresouce scale selector changed for traffic routed canary

[zachaller]

BREAKING CHANGE

We are changing rollouts .status.selector field to report only the stable replicaset for traffic routed canaries that do not use dynamicStableScale. This is needed in order to be able to use HPA's reliably. A little explanation on how HPA. calculate desired pods. There are two methods and formulas for calculating desired pods counts we will be focusing on Value type metrics.

The formula for Value type metrics is as follows desiredReplicas = ceil[currentReplicas * ( currentMetricValue / desiredMetricValue )] The currentReplicas count comes from the selector defined in .status.selector for Argo Rollouts. Before we merge this PR this would be all pods under the Rollout. This causes issues because as we shift traffic to the desired state we end up with a whole bunch of pods not taking any traffic. In theory the number of pods taking traffic will always be equal to .spec.replicas which is also the same value as the stable replicaset, therefore we should report to the HPA the number of pods behind the stable replicaset as a proxy to .spec.replicas.

This change does have the possibility to affect your current HPA configurations. You should make sure that you understand the new behavior and that it works with your HPA's metrics. Chances are high that what you currently have configured is actually broken due to this issue.

Two examples before and after of the formula:

Before this PR

.spec.replicas = 10
setWeight = 50
desiredMetricValue = 50
currentMetricValue = 50
canaryPodCount = 5
stablePodCont = 10
 
desiredReplicas = ceil[currentReplicas * ( currentMetricValue / desiredMetricValue )]
15 = ceil[ (10 + 5) * ( 50 / 50) ]

Here we would want to scale up to 15 pods incorrectly.

After this PR

.spec.replicas = 10
setWeight = 50
desiredMetricValue = 50
currentMetricValue = 50
canaryPodCount = 5
stablePodCont = 10
 
desiredReplicas = ceil[currentReplicas * ( currentMetricValue / desiredMetricValue )]
10 = ceil[ (10) * ( 50 / 50) ]

Here we keep the pod count at 10 correctly.

This is a simplified example due to the dynamic nature of shifting weights during a rollout and metrics changing during those shifts. However, this new behavior is more correct and allows you to construct a metric that is more reliable.

[github-actions]

Published E2E Test Results

  4 files    4 suites   3h 8m 14s ⏱️
113 tests 102 ✅  7 💤 4 ❌
456 runs  424 ✅ 28 💤 4 ❌

For more details on these failures, see this check.

Results for commit 95c0808.

♻️ This comment has been updated with latest results.

[github-actions]

Published Unit Test Results

2 291 tests   2 291 ✅  2m 58s ⏱️
  128 suites      0 💤
    1 files        0 ❌

Results for commit 95c0808.

♻️ This comment has been updated with latest results.

[agaudreault]

LGTM

[agaudreault]

Suggested change

	assert.Equal(t, "{\"status\":{\"selector\":\"foo=bar,rollouts-pod-template-hash=58c48fdff5\"}}", patch)
	expectedPatch := `{"status":{"selector":"foo=bar,rollouts-pod-template-hash=58c48fdff5"}}`
	assert.JSONEq(t, expectedPatch, patch)

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud