Numeric Based Naming for Game Servers

[theminecoder]

Describe the solution you'd like Would love to have an option on fleets to have a numeric based naming system (much like statefulsets do. eg: lobby-0, lobby-1 etc) so that we could deploy lobbies as fleets without having to make custom numbering on top of pod name.

Additional context In Minecraft land, we have the concept of lobby servers where people are connected to before they join a game server. These usually are numbered so that people who want to swap lobbies to find friends can easily tell their friends where to go rather than having to deal with the random suffix. Currently to do this in k8s we have to use statefulsets or manually tell the lobby what number it is but If we could swap it to just using the name that would make life so much easier

[markmandel]

I wanted to dig into this a bit more, because having a numeric based system for naming has lots of consequences, that I'm not sure are good overall.

My initial contention is going to be: "Don't use numbers for lobbies. If you want a memorable and shareable lobby name, generate a human readable name from a group of safe words." (see Docker code) -- but let's dig through it all, and see if I can convince you, because maybe I'm wrong, and you will end up convincing me!

I wave my ✨ magic wand ✨ and now we have a Fleet that will use numeric based naming 😄

I create a Fleet with 3 GameServers.

1. gs-0
2. gs-1
3. gs-2

Sweet, easy so far.

gs-1 decides in needs to shut down, because reasons. No big deal there, I can see that my Fleet has 3 instances, and is now missing gs-1, so Agones creates a new one.

Cool, so far.

The user scales up the Fleet from 3 to 5. Awesome, we now have:

1. gs-0
2. gs-1
3. gs-2
4. gs-3
5. gs-4

Awesome.

Let's scale the Fleet back down to 3.

Does this mean I should get rid of 3+4? But that might not leave us Packed - it could leave us with a non-optimised usage of our resources. That's no good. Uh.

The other option, is to end up with:

• gs-0
• gs-3
• gs-4

😬 that's just ugly. I suppose as we scale back up, we could fill back in 1+2? I dunno at this point.

The race conditions get even worse once we add in Allocation states, and then also Autoscalers. Kubernetes controllers are eventually is self healing, so we could very easily end up with gaps in the lobby names as scale up and down happens.

...so I come back to giving your lobby servers human readable names that provide users the ability to share between friends, and not use numbers, since it's extremely hard to keep it all in expected order.

The only question I have though: Is having an order of Lobby servers scale up and down in the same order actually important? Maybe it is, and I'm missing something about how lobby servers should work?

[roberthbailey]

Can you explain a bit more about this:

so that we could deploy lobbies as fleets without having to make custom numbering on top of pod name

Are you doing custom names today? Or just using the generated random suffixes? You mention that you can use stateful sets or assign numbers to lobbies -- are you doing either (or both) of these things?

I'm curious how difficult it is to assign numbers to lobbies yourself. Is it a similar level of complexity as would be in the stateful set controller or the agones controller?

Is there a benefit to having the numbers be sequential and starting at 0? Would it simplify the problem if you just wanted small numbers (say two digits) and didn't have to keep the numbers tightly packed? That seems like it might reduce the complexity in having a controller assign numbers to your lobbies (making it significantly simpler than the alternative options).

[github-actions[bot]]

'This issue is marked as Stale due to inactivity for more than 30 days. To avoid being marked as 'stale' please add 'awaiting-maintainer' label or add a comment. Thank you for your contributions '

[github-actions[bot]]

This issue is marked as obsolete due to inactivity for last 60 days. To avoid issue getting closed in next 30 days, please add a comment or add 'awaiting-maintainer' label. Thank you for your contributions