Autoscaler WebHook fallback Policy about agones HOT 8 OPEN

This sounds like a good thing 👍🏻

Any suggestions on what the configuration should look like?

from agones.

I would keep the config the same, but the addition of something like Fallback: true on the WebHook config. As it stands, the autoscaler validation does not stop you from setting multiple policies, they just get validated in a specific order. By moving WebHook forward in that list and checking Fallback it could continue down the list to find the next policy to validate, and the implementation would basically work the same.

Should allowing a number of failures before fallback be desired, that too could be added to the WebHook.

from agones.

Actually, that would not work, you would need a FallbackType to specify which type you want to fallback to.

from agones.

I was thinking some kind of nested config under webhook?

apiVersion: autoscaling.agones.dev/v1
kind: FleetAutoscaler
metadata:
  name: webhook-fleet-autoscaler
spec:
  fleetName: simple-game-server
  policy:
    # type of the policy - this example is Webhook
    type: Webhook
    # parameters for the webhook policy - this is a WebhookClientConfig, as per other K8s webhooks
    webhook:
      # use a service, or URL
      service:
        name: autoscaler-webhook-service
        namespace: default
        path: scale
      fallback: # Basically this is a copy of the above - so you could fallback to another webhook - but only allow one level
        policy:
          type: Buffer
          buffer:
            bufferSize: 5
            minReplicas: 10
            maxReplicas: 20

from agones.

Works as well. I would personally not have allowed Webhook falling back to Webhook, because purely from a configuration PoV it looks like more than 1 level could work. There will always be a reason to extend it by one more level. But happy to defer to your experience here.

from agones.

Works as well. I would personally not have allowed Webhook falling back to Webhook

Yeah, but also, if you really want to - should we stop you?

Also it makes our configuration parsing and management easier - the fallback is the same config as the parent - so everything becomes simple, rather than having to keep the fallback up to date with whatever newer config options we come up with down the line.

This also assumes that Helm lets us do some kind of include here that allows us to be at least a little self-referential 😄

from agones.

Yeah, but also, if you really want to - should we stop you?

Fair point 😄

This also assumes that Helm lets us do some kind of include here that allows us to be at least a little self-referential 😄

Helm playing ball is not an experience I have had too often, so it is not something I would bet on.

We would be happy to take this on, if it works for you.

from agones.

Helm playing ball is not an experience I have had too often, so it is not something I would bet on.

Hah. Quite possibly. I'm thinking an include where you can turn off the fallback option, so it doesn't recurse forever.

We would be happy to take this on, if it works for you.

No issue for me, have at it!

from agones.