Closed markmandel closed 5 years ago
/cc @ReDucTor - we talked about this a while back, can you see if this design captures what we discussed?
Looks good, would simplify some of our alternative approaches to the problem.
I'm looking into this.
I'm still working through the bug, I have a test and the logic implemented here, https://github.com/jeremyje/agones/tree/local-ip.
I have a question though, When you say don't create a pod. Does that mean the QA server isn't managed by Agones/Kubernetes and that the goal is to mainly register the existence of the QA server? Bypass all those liveness checks and all that.
Exactly. The active game server likely sits on someone's machine at their desk, and this gives them a way to basically "fake" a Ready gameserver on an Agones cluster, that someone can then connect to within their corp-network.
Then all your other tooling (matchmaking, etc) can still work as per normal - you can even allocate this GameServer - but it makes life easier for development.
Wouldn't you want this server to be marked as Allocated then?
Marking it as already allocated would be game specific
:+1: on what @ReDucTor said - I think in most cases you would want it to be ready, so you can flow through from your matchmaker to your game server just like you would normally.
At the very least, we should start with Ready
and see if people have a desire to have an option to move to Allocated
as well - and we can do that as a separate PR.
WDYT?
Implemented in #558
Problem
For development/QA purposes, it is useful to be able to register a gameserver with Agones, but overwrite it with a specific local IP address, so that it can run through the same Agones system, but QA testers can connect to it, without having to do a full build + deploy pipeline.
Design
We assume all port configuration should be
static
. If theGameServer
has an annotation of:stable.agones.dev/dev-address: "192.168.0.1"
then we intercept this in the controller:Status.State
address.Status.Ports
GameServer
asReady
.Example:
Questions