GameServer Fleets about agones HOT 20 CLOSED

It's probably too early to decide on the fate of this feature. We certainly can have this discussion about recycling terminated game session resources later.

I'd focus on keeping things really simple at this stage though. Meaning that game server allocation represents a new scheduled pod, then when players leave (or game terminated) we delete the GS pod (fleet will ensure to replace it with a fresh one).

from agones.

Like I said, I am OK with using the simple approach for now. I just wanted to mention some use cases where I know it might cause some problems so we don't make an early mistake. I am all for isolation but in some cases, this goes against certain game mode where the players come and go and game "lives" in between interactions with players so recreating it anew might defeat the feature. It all depends on the level of statefulness of game servers which I do not control.

from agones.

Added some notes about how I think an Allocation should occur. These will definitely need 1.9 features.

from agones.

I'm very interested in this, as we never did our "fleets" using Kubernetes APIs. Rather, we had a separate service that monitored our pods and did our warming up, scaling up and down, and what not. At the time I wasn't as familiar with K8s as I am now, so I may have come up with something closer to your approach if I did it again.

from agones.

@EricFortin - I added a section on what to do when the GameServer template changes on a Fleet. I think it should mimic what happens with a Deployment - but we didn't talk explicitly about this. WDYT?

from agones.

@markmandel I think it makes sense and is what I would be expecting of something running on a kubernetes cluster. We just need to adapt it to take the new state into consideration. It should recreate/update only game servers that aren't allocated yet. Moreover, once a non-updated game servers becomes free again, it should be updated before being reallocated. At the beginning, we might solve this issue by recreating any container where games have ended but at some point, games will want persistence for their game server process.

from agones.

SGTM. Adjusted the above to make sure it was clear that Allocated GameServers will not get deleted in the rolling update (but we were thinking the same thing)

I had a question about your statement here:

Moreover, once a non-updated game servers becomes free again, it should be updated before being reallocated. At the beginning, we might solve this issue by recreating any container where games have ended but at some point, games will want persistence for their game server process.

My thought here was very much that when a GameServer shutdown, it gets totally deleted, and a new one would replace it. Thus agreeing with you - the update would occur when a replacement gets created in the Fleet's pool.

From my understanding - we were all working from the assumption/opinion that a GameServer will exit when it has completed a session (sounds like this also needs to be documented).

When you said "but at some point, games will want persistence for their game server process" - do you meant the GameServer is going to reset it back to a zero state? rather than exit, or do you mean something else?

from agones.

From my understanding - we were all working from the assumption/opinion that a GameServer will exit when it has completed a session (sounds like this also needs to be documented).

TL;DR. The assumption holds

My point was mainly that games might want to control server life cycle themselves and not tie it to a game session. It could mean having the server becoming available again to host another "session", which is a concept that is missing at the moment. Should we add it?

Having a server process die at the end of a match applies well to a FPS but not necessarily to a PvE but I guess we can still consider that the server process will exit when it is ready, or instructed to become so, to be swapped out by an updated container. It might just take a long time(hours, not weeks).

from agones.

I'm wondering if the Allocated concept is the same as currently hosting a session ?

from agones.

@EricFortin We most likely want to create new game sessions in a clean environment every time and not reuse previous process.

In a PvE, we wouldn't want cheaters to leave any bad states in the engine memory or on disk.

I suppose there's a trade off to be made between good isolation and initialization time with "hot" server processes. I'd rather have better isolation. What do you think?

from agones.

@EricFortin Ah yes - good point (thanks for the explanation). I think when we start looking more at PvE - there are several strategies we could look at - maybe a SDK method of Deallocate() rather than Shutdown() - or maybe it's a configuration option on Shutdown() it returns to the pool rather than gets deleted. But I would defer this to a later date for the moment.

My current thought for getting an Allocated GameServer - is to essentially follow the Deployment paradigm:

• We have a GameServerAllocation CRD that you can then create a via the yaml / Kubernetes api.
• When the GameServerAllocation is created, it's the GameServerAllocation that is returned is populated with the details of the GameServer that is allocated (need 1.9 webhooks for this).
• The GameServer state is also moved to Allocated at the same time.
• GameServerAllocations can't be edited - only created and deleted (current thought being if you delete the GameServerAllocation or the GameServer they are both deleted )?

This stays nicely within the K8s paradigm. WDYT? (I can also write it up above with some examples if that helps)

from agones.

@alexandrem I'm more inclined as well to isolation - but I feel like we could try with better isolation (processes get killed), and see what the actual implications are with a real system, and make pragmatic decisions once we have more data (i.e. then add options to move out of Allocation if needed), rather than decide at this stage. WDYT?

from agones.

@EricFortin Those longer lived game sessions where players come and go (and remain non populated for some time) are an interesting use case.

I suppose in the end this is controlled solely by the SDK; is game terminated or not. If not terminated, then we definitely want to keep the game session in "allocated" and not touch them. Actually, they probably should have a different state so we can track those who are empty so we can possibly remove them when the fleet size is being decreased.

from agones.

Actually, they probably should have a different state so we can track those who are empty so we can possibly remove them when the fleet size is being decreased.

This is an interesting question - one could argue, that if the GameServer becomes empty (maybe for a certain time) this is implementation specific, and the actual game server code should just call SDK.Shutdown() when it's been empty for a while - and then the Fleet will just do what it needs to do at that point forward.

from agones.

For those cases where life cycle is not totally dependant on game sessions, there will most probably be a "god" service that manages it all and can replace an instance by directing players to the new instance and ultimately instructs the old instance to shutdown. This use case also affects scale down event since even if we taint the node, it still can't be recycled if it's hosting a game server. This is out of scope for now but I think we will need a way to provide this feedback so something can react.

from agones.

Currently working on GameserverSets (the Fleet version of ReplicaSets) on my fork over here. Will finalise, and then submit for PR before doing the Fleet work that overlays this work.

from agones.

Start of "Creating a Fleet creates a GameServerSet" first PR has started over in this repository and branch

from agones.

Fleet Allocation work started over here

from agones.

Work on doing a straight replace when updating Fleet's GameServer details, can be found over here:
https://github.com/markmandel/agones/tree/feature/fleet-replace

from agones.

Rolling update strategy work is here:
https://github.com/markmandel/agones/tree/feature/fleet-rolling

from agones.