Return Counter and List data when Allocating a GameServer

[markmandel]

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

Two use cases where returning Counts and/or Lists back with Allocation data.

Rooms per session.
Assuming you have a multi-tenant GameServer with different ports for each "room", and you increment a GameServer counter, such as rooms with an Allocation request, returning the current room count means you can know atomically which room you are currently on, and therefore while port to use by convention.

Player Backfill
If you want to ask an Agones cluster "do you have room for one or more player to be backfilled on a cluster" you can use ListSelector -- but without looking at the GameServer itself, you don't know what the actual count is on the GameServer.

This way you could periodically ask a cluster "do you have room for 1 to 10 players within your cluster?" and get back a GameServer, and without having to do another hop, know how many players you need to backfill in that operation.

(if anyone has any extra use cases, please feel free to add below -- actively collecting use cases)

Describe the solution you'd like
Attach it to https://agones.dev/site/docs/reference/agones_crd_api_reference/#allocation.agones.dev/v1.GameServerAllocationStatus

Not quite sure where 🤔 could just be counters and lists like we have in GameServer.Status - that would work for me.

Describe alternatives you've considered
Leave things as they are, but that requires more work by the end user.

Additional context

N/A - all because of offline conversations.

[katsew]

We have a similar use case in implementing the High Density GameServer pattern.
When we request a GameServer allocation, we would like to be able to use list to pre-populate the room in GameServer in batches.
This will reduce the number of actual allocation requests, which is more efficient.
However, the current implementation of CountsAndLists does not necessarily append all list items defined. If you try to fill more than the capacity, you will get an error and the GameServer allocation will succeed with only some of the items filled.
In this case, the expected state of the GameServer and the actual state of the GameServer will inevitably be out of sync.
To solve this problem, it would be helpful if counts and lists are returned in the allocation response as suggested.

[katsew]

In our case, we prefer that the results of ListAction and CounterAction are also returned.

For example, the following form.

Request:
{
  "lists": {
    "rooms": {
      "addValues": ["room-3", "room-4", "room-5"]
    }
  },
  "gameServerSelectors": [
    {
      "gameServerState": 1,
      "lists": {
        "rooms": {
          "minAvailable": 1
        }
      }
    },
    {
      "gameServerState": 0
    }
  ]
}

Selected GS:
kind: GameServer
metadata:
  name: gs-1
status:
  state: Allocated
  lists: {"rooms":{"capacity":3,"values":["room-1", "room-2"]}}

Result of GS:
kind: GameServer
metadata:
  name: gs-1
status:
  state: Allocated
  lists: {"rooms":{"capacity":3,"values":["room-1", "room-2", "room-3"]}}

Response:
{
  "gameServerName": "gs-1",
  "ports": [],
  "address": "",
  "addresses": [],
  "nodeName": "",
  "source": "",
  "metadata": {},
  "lists": ["room-1", "room-2", "room-3"]
  "listAction": {
    "rooms": {
      "addedValues": ["room-3"]
    }
  }
}

[markmandel]

In our case, we prefer that the results of ListAction and CounterAction are also returned.

Can you explain why? I'm curious as to the use case.

Also, since you get the results, and you know what you send, you could do the diff yourself quite easily.

[katsew]

In our case, we prefer that the results of ListAction and CounterAction are also returned.

Can you explain why? I'm curious as to the use case.
Also, since you get the results, and you know what you send, you could do the diff yourself quite easily.

I thought that if we got the result of appended values, simply add them into our storage with the allocated GameServer data without calculating the diff of request and response.
I plan to cache them into our storage to use these roomIDs from other hosts to connect to the GameServer without sending request to allocator service.

Also, since you get the results, and you know what you send, you could do the diff yourself quite easily.

You are right, we can calculate the diff easily so it's not essential.

[katsew]

@markmandel

Are you already working on this issue?
If not, would you mind if I tackle it?

[markmandel]

I'm focused on some other stuff at the moment, so if you want to have a go, please feel free!

If you have questions, feel free to drop them here, or come by #development in Slack!