RFC: In-place Agones Upgrades about agones HOT 7 OPEN

Are we requiring that all changes (for Feature Gate, SDK Server, SDK Client, Config) must go from Alpha -> Beta -> Stable? Or are we allowing for changes to go Alpha -> Stable (skipping Beta), or Beta -> Stable (skipping Alpha)?

I think Beta -> Stable (skipping Alpha) should be a supported pattern for non-contentious features that we want to allow disablement of (think infrastructure features that might break things, but we think are ok to default on).

I would prefer not to support Alpha -> Stable - we don't get a lot of coverage from Alpha testing anyways, so I have trouble imagining a scenario where Alpha -> Stable makes sense.

from agones.

LGTM - just a couple of extra thoughts:

UI/UX

The system must function normally during an upgrade, from a user's perspective

Adding an item: "Should not delete / interrupt existing GameServers or Fleets

(probably implied, but right now the Helm template will delete Fleets, GameServers, etc- so would be good to be explicit).

Client SDKs

May also want to make a note that if the proto doesn't change, but we update SDKs, then the end user can stay with their current SDK version until such time as they are willing to spend the time to upgrade.

Configuration / Helm Values

As part of this work, should we spend some time making a jsonschema for helm? Or at least start? That would be a step in the right direction of ongoing maintenance, and warnings about deprecation (in theory?).

from agones.

Are we requiring that all changes (for Feature Gate, SDK Server, SDK Client, Config) must go from Alpha -> Beta -> Stable? Or are we allowing for changes to go Alpha -> Stable (skipping Beta), or Beta -> Stable (skipping Alpha)?

from agones.

LGTM - just a couple of extra thoughts:

UI/UX

The system must function normally during an upgrade, from a user's perspective

Adding an item: "Should not delete / interrupt existing GameServers or Fleets

(probably implied, but right now the Helm template will delete Fleets, GameServers, etc- so would be good to be explicit).

Good call out, added to UI/UX

Client SDKs

May also want to make a note that if the proto doesn't change, but we update SDKs, then the end user can stay with their current SDK version until such time as they are willing to spend the time to upgrade.

Agreed, added to Client SDKs

Users are not required to update Client SDK in game server binaries except for SDK proto deprecations, or breaking Alpha API changes. We foresee that evaluating updating Client SDKs in game server binaries will be yearly toil, if using Stable APIs, or semiannual toil, if using any Beta API; this toil can be as simple as verifying that there were no deprecations in the period involved. Given how stable our core APIs have been, it may be possible to go multiple years without updating the Client SDK.

Configuration / Helm Values

As part of this work, should we spend some time making a jsonschema for helm? Or at least start? That would be a step in the right direction of ongoing maintenance, and warnings about deprecation (in theory?).

I like it! Added to Config:

JSON schema for helm: We should add a JSON schema for our Helm chart. If we've made a breaking change in our Helm charts, this will make it more obvious to our users. (TBD: It could also potentially give us a way to enforce version horizons, since we could intentionally change schema elements in a way that there would be an error if you tried to skip too far at once.)

from agones.

This the one @markmandel

from agones.

This is exciting!

In UI/UX where you mention an upgrade to 1.41 fails, upgrade to 1.42 without rollback to 1.41 is not supported. Do you mean 1.40? Or does it means we need to re-apply 1.41 until it succeeds?

I also think we should mention what will happen with metrics during the upgrades. I would be in favor of no disruption 😄

from agones.

I also think we should mention what will happen with metrics during the upgrades. I would be in favor of no disruption 😄

Ooh that's a good point. We probably need some sort of guarantees on metrics between versions as well. (hello client-go metrics that just stopped working -- that would mean we need to fix those!).

from agones.