In-place Agones Upgrades: Storage Compatibility about agones

[markmandel]

Apply Default

I like the approach. But you would want to ApplyDefaults() here:

agones/pkg/gameservers/controller.go

Lines 389 to 396 in 4bb6731

	gs, err := c.gameServerLister.GameServers(namespace).Get(name)
	if err != nil {
	if k8serrors.IsNotFound(err) {
	loggerForGameServerKey(key, c.baseLogger).Debug("GameServer is no longer available for syncing")
	return nil
	}
	return errors.Wrapf(err, "error retrieving GameServer %s from namespace %s", name, namespace)
	}

Rather than where you specified, as enqueing only enque's the namespace/name of the object, not the object itself - giving the best opportunity to get the latest Object at the time of syncronisation.

Everything else.

LGTM! I like the approach 👍🏻

[zmerlynn]

Apply Default

I like the approach. But you would want to ApplyDefaults() here:

You're right. It might be nice if we had a helper function here that's basically "Get and Default" (for the case of inline changes like you just did for the migration controller), but agreed on the placement.

[igooch]

A couple of proposed changes on this:

We should create a new policy that any new required CRD fields must be non-nullable, and have a default specified in the CRD itself. This means on install all custom resources will immediately have the new field with the default.

• This covers the case of a new controller requiring a field to be non-nil.
• Any new non-required fields may be marked nullable: true in the CRD. The expectation here is that a controller will not panic when a non-required field is nil.
• Reiterating from the main comment that any fields removed in the CRD on upgrade will immediately be pruned (deleted) from all objects by Kubernetes.

I don’t think we need to update the ApplyDefaults() for Game Servers. As Game Servers are inherently ephemeral, there is no need to make changes to the Game Servers. By design we allow for skew between the controller and SDK version, and any field changes can be managed by the CRD itself.

• The Game Server state is maintained in memory, and is only written back to the kube-apiserver (.GameServers().Update()) during creation, starting, allocation, unhealthy states, and deletion.
• Any Ready and Allocated Game Servers pods have the existing configuration (with the exception of any new non-nullable and defaulted CRD fields), and will work with the existing SDK image.
  • A side note here that on a Fleet rollout after an Agones upgrade the Fleet will create a new Game Server Set at the new configuration, and all existing Game Servers will eventually be deleted and recreated on the new Game Server Set per the Fleet’s rollout strategy.
• As new Game Servers are created they will be at the new configuration. This includes all configuration relevant to rendering the Game Server, such as the version, the feature flags, and the sdk-server configuration.

And a few additional comments:

• The user can initiate a rollout of the Fleet via a label update to change over all Ready Game Servers to the new configuration.
  • The Fleet spec and Game Server Set configuration should upgrade to the new configuration on user initiated Fleet rollout.
  • On update, Fleet annotation should be updated to the most recent SDK version. This is for logging purposes.
• The Fleet status and Game Server Set status should reflect the new configuration regardless of whether or not a Fleet upgrade rollout has begun.
  • For example, downgrading from an Agones version with CountsAndLists in Beta (on by default) to an Agones version with CountsAndLists in Alpha (off by default) will turn off the feature gate CountsAndLists. The Fleet will drop any status relating to CountsAndLists as the feature is no longer on. This is a clear indication to the user that the feature flag is turned off.