Agones: Cannot update Fleet and set replicas to 0 in same transaction

[bburghaus]

What happened:
Cannot update a Fleet field and scale down to 0 in the same update. This creates a lingering GameServerSet that won't scale down.

What you expected to happen:
Fleet will update and scale down to 0.

How to reproduce it (as minimally and precisely as possible):
Edit any .Spec.Template field and set .Spec.Replicas to 0 in the same update transaction.
Use RollingUpdate strategy:

Strategy:
    Rolling Update:
      Max Surge:        25%
      Max Unavailable:  25%

Anything else we need to know?:
In calculating the maxUnavailable, the function intstr.GetValueFromIntOrPercent() will always return 0 if the replicas is 0. Setting the replica count on the old GameServerSet will then never change.

newReplicasCount := fleet.LowerBoundReplicas(gsSetCopy.Spec.Replicas - unavailable)

This results in a repeated event

Scaling inactive GameServerSet [gss] from 1 to 1

and the old GameServerSet lingers.

NAMESPACE         NAME       SCHEDULING   DESIRED   CURRENT   ALLOCATED   READY   AGE
[namespace]  [fleet]-new       Packed     0         0         0           0       154m
[namespace]  [fleet]-old       Packed     1         1         1           0       19h

Fleet:

NAMESPACE      NAME    SCHEDULING   DESIRED   CURRENT   ALLOCATED   READY   AGE
[namespace]   [fleet]   Packed       0         1         0           1       19h

It's possible to separate this out into two separate transactions, but we would like to be able to change certain fields when we are scaling down to 0 in a single helm call

Environment:

• Agones version: 1.10.0
• Kubernetes version (use kubectl version): 1.16

[markmandel]

Thanks for submitting this bug report!

I'm trying to replicate this against the current development version, you can see my new e2e test here

I'm struggling to replicate the issue though? Can you see anything I should change in my test?

We did recently implement the new rolling update to include checking if a GameServer is Ready or not. I'm wondering if that will have fixed things.

[bburghaus]

I ran your test locally and it seems that this is fixed in 1.14. In the older versions I tested (1.10-1.13) the test can reproduce the bug. Is #2033 the change you're referring to?

[markmandel]

That would be the one!

I'd like to submit the e2e test as a PR, just to ensure we don't get a future regression - but you happy for me to close this issue once that has been submitted? Looks like it is fixed in a newer version of Agones.

[bburghaus]

Yes that works for me, thanks Mark!

[roberthbailey]

If you need to use an older Agones version, the fix as implemented in RollingUpdateOnReady can be enabled using a feature gate back to version 1.9.0: https://1-13-0.agones.dev/site/docs/guides/feature-stages/#feature-gates