Total replica count should be capped during a rollout

[johnniee]

Summary

According to the 'important' section here - Argo Rollouts makes the best effort to achieve the percentage listed in the last setWeight step.

In the case where the setWeight is 15%, the Rollout attempts to get there by rounding up the calculation (i.e. the new ReplicaSet has 2 pods since 15% of 10, rounds up to 2 and the old ReplicaSet has 9 pods since 85% of 10, rounds up to 9).

Is there any other way I can achieve a situation where the rollout will always respect the number of the replica count I provided in the deployment file? Using traffic management won't help here since It's a producer-consumer platform.

Use Cases

I'm using Argo-Rollouts for my Kafka consumers. And the number of my replicas should be equal and constant to the number of Kafka partitions. In case the rollout will exceed the number of the desired replicas in my manifest it might cause issues in my system. So it should be maxOldRevision + newRevision == totalReplicaCount.

---

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

[johnniee]

Hi @huikang,
I created a PR that should handle this use case:
#1743
I'll be glad to hear if you have any feedback!

[Vignesh-Au]

@johnniee Can you please share an example configuration for argo rollout canary release for a kafka consumer application? I am new to argo rollout and would like to know how weight distribution happens for a kafka consumer app.

[johnniee]

Hi @Vignesh-Au, here's a snippet for our canary strategy we are using for our Kafka consumers:

canary:
  maxSurge: 0
  maxUnavailable: 1
  stableMetadata:
    labels:
      role: "stable"
      canary: "false"
  canaryMetadata:
    labels:
      role: "canary"
      canary: "true"
  steps:
  - setWeight: 1
  - pause: { }

The maxSurge: 0 will make sure there won't be any 'spare' replicas during the deployment.

[Vignesh-Au]

Thanks @johnniee.