Comments (8)
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.
Related Issues (20)
- Release 1.40.0 HOT 1
- Direct connection to a GameServer/Pod without NAT HOT 14
- [mTLS]: allocator server can not verify client certificate when client certificate auto renew HOT 2
- Refactor simple-game-server
- `make gen-all-sdk-grpc` is ineffective for nodejs HOT 9
- [Docs] Single source of truth for example yaml files HOT 2
- Fleet autoscaler scale down delay HOT 1
- metadata.finalizers: "agones.dev": prefer a domain-qualified finalizer name to avoid accidental conflicts with other finalizer writer HOT 1
- Implement Count functions in SDKServer, and write e2e tests HOT 1
- sdkserver: add functionality to remove game server annotations
- sdkserver: add functionality to set multiple game server annotations at once HOT 4
- [e2e] Document the best path for making changes to simple-game-server for e2e tests HOT 1
- Add runAsUser, runAsGroup, and allowPrivilegeEscalation to helm chart for Agones containers HOT 8
- Release 1.41.0 HOT 1
- Fix connection-draining flakes in TestAllocatorAfterDeleteReplica / /TestGameServerCreationRightAfterDeletingOneExtensionsPod
- Update Node.js Page to Reflect that Counters and Lists is Implemented
- `make build-images` fails with no REGISTRY variable set HOT 1
- Add AppEngine cleanup to appropriate CloudBuild scripts. HOT 2
- Distributed defaults to using ListSortedGameServersPriorities when CountsAndLists is enabled HOT 2
- https and CORS for agones-ping http service HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from agones.