-
Notifications
You must be signed in to change notification settings - Fork 188
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Validate the racks #2056
Validate the racks #2056
Conversation
I think this is close, just needs a tweak. We likely still want to be able to schedule some things on the smaller racks we add, but don't want a singular under sized rack to limit placement among the others. I think the hard coded list should be what informs if we choose |
Close, but this is still a bit too restrictive. This will essentially not let anything schedule on unexpected racks, but doesn't solve the issue that the number of racks will still make it think that something is saturated too early. Check out the double numPerRack = numDesiredInstances / (double) rackManager.getNumActive();
if (racksAccountedFor < rackManager.getNumActive()) {
... The rackManager.getNumActive() is what gets us right now when we accidentally do something like add a single host in a new rack. Singularity RackManager then thinks there are 4 for example, but only 3 actually have sufficient capacity for scheduling. We want to do something like using the count of expectedRacks here vs rackManager.getNumActive() (probably falling back to rackManager in the case that the expectedRacks is empty/unspecified, which should be the default) |
Looking good, if all tests are still passing let's give it a go in staging 👍 |
Verified that scheduling still works normally on staging, added a unit test just to be safe. |
🚢 |
Status: Work in progress 🚧
Description
we want to validate the singularity racks because adding new instances in racks that singularity doesn't know about causes scheduling issues
Issue: https://git.hubteam.com/HubSpot/PaaS-Run/issues/1102
Todos