feat: allow maestro to deal with multiple matches per game server #646
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
hspedro
reviewed
Oct 31, 2024
| MaxMatches int `validate:"required,min=1,max=30"` | ||
| // MinFreeSlots defines the minimum number of free slots that a room must | ||
| // have to become available for allocation. | ||
| MinFreeSlots int `validate:"required,min=1"` |
There was a problem hiding this comment.
we should add max=30 here because the upper limit is MaxMatches, right? And in addition we'll validate one value against the other as well but max=30 we "gain" a validation prior to us checking one against the other
* feat: add new metrics * fix: metrics reporter tests * fix: protobuf linter offenses * fix: update buf dependencies before running linter
reinaldooli
added a commit
that referenced
this pull request
Nov 25, 2024
* chore: upgrade and remove some dependecies * feat: allow maestro to deal with multiple matches per game server (#646) * feat: allow maestro to deaul with multiple matches per game server * fix: removing cooling status * feat: add new metrics (#649) * feat: add new metrics * fix: metrics reporter tests * fix: protobuf linter offenses * fix: update buf dependencies before running linter * fix: add max validation to minFreeSlots fields
reinaldooli
added a commit
that referenced
this pull request
Nov 25, 2024
* feat: add occupied slots to game rooms api * fix: rename api parameter * fix: failing tests * chore: upgrade and remove some dependencies (#644) * chore: upgrade and remove some dependecies * feat: allow maestro to deal with multiple matches per game server (#646) * feat: allow maestro to deaul with multiple matches per game server * fix: removing cooling status * feat: add new metrics (#649) * feat: add new metrics * fix: metrics reporter tests * fix: protobuf linter offenses * fix: update buf dependencies before running linter * fix: add max validation to minFreeSlots fields
reinaldooli
added a commit
that referenced
this pull request
Jan 22, 2025
* feat: add occupied slots to game rooms api (#641) * feat: add occupied slots to game rooms api * fix: rename api parameter * fix: failing tests * chore: upgrade and remove some dependencies (#644) * chore: upgrade and remove some dependecies * feat: allow maestro to deal with multiple matches per game server (#646) * feat: allow maestro to deaul with multiple matches per game server * fix: removing cooling status * feat: add new metrics (#649) * feat: add new metrics * fix: metrics reporter tests * fix: protobuf linter offenses * fix: update buf dependencies before running linter * fix: add max validation to minFreeSlots fields * feat: removing unused field minFreeSlots * chore: update dependencies * fix: project dependencies * chore: upgrading go version on CI * chore: upgrade docker image for build step * fix: backward compatibility with exiting schedulers * fix: linter offenses * fix: adding default match allocation configuration when not provided * fix: missing match allocation configuration * feat: create simulation service * fix: missing license headers * fix(policy): compute desired number of matches before rooms (#654) If we first divide the number of running matches per maxMatches we might end up with a number between 0 and 1, which is quirky when using math.Ceil because it would propagate the error to when computing number of desired rooms. To simplify and fix this, instead we now compute how many matches is the desired and then convert the final number to the amount of rooms/instances/pods needed to provide this number of matches: 1. How many running matches we have? * Get the value from the redis: scheduler:<scheduler_name>:occupancy 2. How many matches do we need to have based on readyTarget? * Divide running matches by 1 - readyTarget 3. How many game rooms are needed to provide this amount of matches? * Get the desired number of matches and divide by the max number of matches per room as defined in the scheduler * fix(allocation): maxMatches limit to 35 (#655) Some games might choose to run larger pod resources and increase number of matches running in each room/instance, thus increasing from 30 to 35. The limit in the max matches is useful so configuration stays in a sane number to help in autoscaling and roundings. * fix: setting running matches when not given * fix: adding transition from unready to active * fix: adding transition from occupied to active * fix: multiple matches status calculation * feat: report metric with scheduler max matches * fix: sync scheduler before sending metrics --------- Co-authored-by: Pedro Soares <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request introduces changes to enable Maestro to manage multiple matches per Game Server effectively.
MatchAllocation Configuration: Adds a MatchAllocation block to the Scheduler configuration with two parameters: MaxMatches (maximum number of matches per game room) and MinFreeSlots (minimum number of free slots required for a room to be considered available again).
Backward Compatibility: If MaxMatches is set to 1 (default value), Maestro will continue its previous behavior without slot-based scaling. The new match-based calculations apply only when MaxMatches is greater than 1.
New Game Server States: Introduces two new statuses for Game Servers with MaxMatches greater than 1:
These updates provide more granular control over room availability and autoscaling, helping to optimize server utilization when using a multiple-matches-per-room strategy.