Is it possible to not use "rollouts-pod-template-hash"?

[sedflix]

When using “trafficRouting”, Rollout automatically adds rollouts-pod-template-hash to either the Service or Destination Rule.

Would it be possible for Rollout to use selectors like role: stable or role: canary instead of relying on rollouts-pod-template-hash?

We are running a multi-cluster Istio setup with multiple control planes on a single network. The addition of rollouts-pod-template-hash as a selector label in the Service or Destination Rule causes us to lose namespace sameness across the cluster, ultimately affecting multi-cluster load balancing. The same would happen with Gateway API(for example GKE usage of Gateway API to support multi-cluster load balancing)

For example, the configuration below makes the service single cluster because "rollouts-pod-template-hash" is unique for each cluster. Therefore, we loose our ability to do any sort of multi-cluster routing or failovers.

apiVersion: v1
kind: Service
metadata:
  name: istio-rollout-stable
  namespace: rollouts-demo-istio
spec:
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: http
  selector:
    app: istio-rollout
    rollouts-pod-template-hash: 597c465644
  type: ClusterIP

Question)
Is there any possible way to use Traffic Management without losing this multi-cluster load balancing?

[sedflix]

It's related to #3108 .

[kostis-codefresh]

The problem I see that ephemeral metadata would not work in the following case.

You have version 1.4 running (label stable)
You start a canary with 1.5 (label canary)

Then in the middle of the process somebody does a hotfix with 1.6 (a perfectly possible scenario). What label can we use there?
And the cycle can continue, somebody does another hotfix with 1.7

So Argo Rollouts needs a way to differentiate all those "waves" of pods"

[sedflix]

Shouldn't both 1.6 and 1.7 have the "canary" metadata? 🤔

• start a canary with 1.5 (label canary): replicaset n created with label canary and version 1.5
• middle of the process somebody does a hotfix with 1.6: replicaset n+1 created with label canary and version 1.6. replicaset n is scaled down and rollout starts from scratch.

[kostis-codefresh]

Not always. Let's say that in my organization for some specific reason I want to differentiate between pods of 1.6 and 1.7 Maybe while I am applying the hotfix I want to gather metrics only from 1.7 and not 1.6. Maybe I have selected a scale down period of 30 minutes or something similar.

All I am saying is that your suggested changes needs to become a proper proposal that includes

• The impact of this change as it is significant for how Argo Rollout works
• An explanation of several common and uncommon scenarios of how this would work (including edge cases)
• A clear way of migration for existing users or explanation on how to switch if both behaviors are to be kept.

[sedflix]

#4093 (reply in thread)

Doesn't this happen in the current Argo Rollout rollout as well?

[sedflix]

The only required change concerns the type of selectors applied in traffic routing (e.g., "Service" or "Destination Rule") to address multi-cluster load balancing and namespace sameness.

The existing functionality for creating and labeling ReplicaSets will remain unchanged. Specifically:

• We will continue labeling ReplicaSets with "rollouts-pod-template-hash".
• Analysis templates and metric collection will function as they do now.
• Argo Rollouts can still differentiate between pods based on the hash and ReplicaSet.

Under this approach, the system will dynamically assign pods with “stable” and “canary” labels as it currently does using ephemeral metadata. However, instead of configuring the hash within the traffic routing selector, we propose that Rollouts configure ephemeral metadata within the selectors.

Proposal

Introduce an optional feature that allows configuring the traffic routing selector using deterministic labels rather than the randomly generated "rollouts-pod-template-hash".
These labels should be configurable in several ways like referring to a rollout label or replica set label.

What can be these labels?

• Ephemeral metadata: But it may introduce propagation delays, especially when managing a large number of pods.
• Image Version Label: This does not work during configuration changes. I find the tradeoff acceptable in some scenarios.
• Helm Chart Version Label: This does not work for non-helm-chart stuff. But this would work for me perfectly as we enforce new helm chart version for each deploy.