Get internal game server version

[fooock]

Is your feature request related to a problem? Please describe.

I want to be able to retrieve the current internal game server version to manage some operations, like if a GameServer should be recreated with an update.

Describe the solution you'd like

I like the idea to report the game server version using the SDK. Maybe a new method to set it like:

err := sdk.SetGameVersion(value)

and retrieve its value using:

value := sdk.GameServer().Version()

If version is not set, value is empty.

Describe alternatives you've considered

Using labels and/or annotations:

err = sdk.SetAnnotation("game-version", "1.37.51")
err = sdk.SetLabel("game-version", "1.37.51")

$ kubectl describe gs
Name:         csgo-server
Namespace:    default
Labels:       agones.dev/sdk-game-version=1.37.51
Annotations:  agones.dev/ready-container-id: docker://83ac1b7903fcc2a7ceec1362c21d511f5465813f78553b01a5492558eb6a41aa
              agones.dev/sdk-game-version: 1.37.51
              agones.dev/sdk-version: 1.5.0
API Version:  agones.dev/v1
Kind:         GameServer
...

[markmandel]

What downside is there to using a label or annotation for this?

This is a lot of work (new sdk commands, new crd storage space, implementations across multiple languages), all to store what is essentially an arbitrary key value pair.

I'm strongly inclined to say no to this request and close the issue, unless people can provide a good reason not to?

[fooock]

You are right, its a lot of work, but the main reason for me to propose this is that the game server version is always the same while the game is running, and using labels/annotations can break this behavior because these can be deleted/modified. Also, it is a way to standardize how the solution manages game server versions across different games. One common method for all.

[EricFortin]

Couldn't you use container image tag for this purpose?

[markmandel]

the main reason for me to propose this is that the game server version is always the same while the game is running, and using labels/annotations can break this behavior because these can be deleted/modified.

But in your design, the version can be changed through the SDK? So it is modifiable, and has the same issues?

Couldn't you use container image tag for this purpose?

@EricFortin raises an excellent point. Wouldn't something actually immutable like the game server container image tag be a better fit?

[fooock]

Yes, you are right. The version can be changed through the SDK, but this logic is inside the container of the game server and cannot be changed from outside. Anyway, I'm using labels and annotations for this and at the moment without any problems. Just post the idea to see if it makes sense also for others.

The argument of @EricFortin is not valid for me, because I have different life cycles for container updates and game updates (game server data doesn't live inside the container, is an external volume).

[markmandel]

.... but this logic is inside the container of the game server and cannot be changed from outside

But anything that is stored on a CRD is modifiable from the outside? Unless we put webhooks in place for a GameServer to stop updates, which we've avoided up until this point for a variety of reasons.

As an aside, who is running around your cluster editing your labels and annotations :smile: ?

I think the other issue here, is that for many people, it's not just one version number - it's version numbers for multiple containers - main, sidecars, etc, and then maybe also, like you, data in a file storage.

So I'm not sure that having a single version solution like this actually makes sense, since I don't see how there is a generic solution to this problem.

But I'm happy to be proved wrong!

[fooock]

But anything that is stored on a CRD is modifiable from the outside?

Yes sorry, I forgot that point.

Unless we put webhooks in place for a GameServer to stop updates, which we've avoided up until this point for a variety of reasons.

Interesting point, what reasons?

I don't see how there is a generic solution to this problem.

But the data in storage is the actual game server (but not in execution). I give you an example to explain this problem that I currently have to manage the versions of the game servers.

Spoiler

*I haven't tried it yet using Agones, but I imagine it will work using labels/annotations, then we can close this issue*

Imagine that I have a large fleet of servers in version 1.0.0 and all clients check the version of the game server before connecting to it. As long as the versions between client and server are correct, everything works without problems.

When the client gets an update that breaks connections to legacy servers like our fleet of servers, the connections are broken and we need to recreate our fleet. For me is not a generic problem. I think that Agones should be capable of reacting to these situations when we need to start a new fleet of servers and dispose of the current one. Like in the Fleet updates guide in the Recreate strategy, but executed automatically when a new game server version is available.

I think that this approach is necessary when the containers of game servers don't save a state, and for me, the easiest way to do it is checking the version of running game servers. Also, with this approach, we can continue using the same sidecar, main, etc containers, because only changed the data of the game.

As I said, probably this problem can be solved using the Agones API and labels/annotations. I will try it. We can close this issue but the conversation about this is interesting...

[markmandel]

When the client gets an update that breaks connections to legacy servers like our fleet of servers, the connections are broken and we need to recreate our fleet.

I would run different fleets for each version, so you can adjust each accordingly, and have different allocations based on version -- which would be filtered by label anyway. Especially since client updates take time to rollout to 100% of the population.

Agones should be capable of reacting to these situations when we need to start a new fleet of servers and dispose of the current one. Like in the Fleet updates guide in the Recreate strategy, but executed automatically when a new game server version is available.

This sounds like some kind of CI/CD problem that rolls out new versions/creates new fleets as new versions of your gameserver get published to some sort of registry. So yeah, you would need some custom glue to put this all toghther, seems to me like its outside the scope of Agones.

As I said, probably this problem can be solved using the Agones API and labels/annotations. I will try it. We can close this issue but the conversation about this is interesting...

Yeah, I think this is the right way to go. But yes, it is an interesting conversation!

[markmandel]

I'm doing some cleanup - seems like this issue can be closed as a wontfix. Please reopen if you disagree.