Corner case during percent evaluation of maxUnavailable & canary rollout

[agrawal93]

Hi Everyone,

I would just like to bounce off a corner case which I've discovered, where maxUnavailable gets rounded down and canary step setWeight gets rounded up based on the code present below:

argo-rollouts/utils/replicaset/replicaset.go

Line 371 in 671e52d

unavailable, err := intstrutil.GetValueFromIntOrPercent(intstrutil.ValueOrDefault(maxUnavailable, intstrutil.FromInt(0)), int(desired), false)

argo-rollouts/utils/replicaset/canary.go

Line 46 in 671e52d

desiredNewRSReplicaCount = int32(math.Ceil(float64(rolloutSpecReplica) * (float64(weight) / 100)))

Example:
Say we have an Argo Rollout (with 4 replicas) running in a cluster with the below limitations.

	CPU	Memory
Limitations per pod	1 core	2 GB
Overall capacity	4 cores	8 GB

With the above limitations, there's no room for surging during rollout. We have configured the strategy as follows:

maxSurge: "0"
maxUnavailable: "30%"
strategy:
  canary:
    steps:
      - setWeight: 30

The way it gets evaluated is:
maxUnavailable Pods = floor(30% of 4) = 1
canary step weight = ceil(30% of 4) = 2

And due to limitation on the resources, this eventually results in ReplicaFailure, as no resources are available for the 2nd pod.

I would like to know the thoughts regarding the same, and whether this can be avoided from Rollouts Controller end.

[agrawal93]

@alexmt @jessesuen Could you please help me on this thread, or assign the relevant point of contact to answer this thread. Thanks!