You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit e868c8a
Browse filesBrowse the repository at this point in the historyBrowse files
Hold back hosts with a backlog of VMs still starting
The symptom this addresses is a burst of deployments all landing on one
host and then sitting in Starting for minutes instead of seconds, while
that host works through a queue of starts its storage and agent command
path cannot absorb.
Nothing in the algorithm saw that. Capacity is not charged until a VM
reaches Starting, which is after the allocator has returned, and the
utilisation average is a sample interval and a half life behind, so a
burst is over before either notices. The recent-start term is the
closest thing to a guard and it cannot do the job: it counts VMs whose
state changed within a window, so a VM stuck in Starting for ten minutes
stops counting after five - the signal decays fastest on the hosts that
are worst off - and its contribution is capped at 0.111 of the score, so
a host with 200 VMs stuck in Starting ranks the same as one with 50.
Count the VMs actually in Starting instead, and use it as a gate rather
than a weight. It does not expire while the condition persists, it is
read fresh on every ranking rather than sampled, and a gate cannot be
outvoted by the other terms. It costs nothing: the per-host VM count
query already filters on vm.state, so it is one more aggregate in a
query that was already being made.
Held-back hosts are still never dropped, only moved down the list, so
this cannot turn a deployment that would have succeeded into an
InsufficientServerCapacity failure. Within the held-back group the order
is by starting count, so if every host is backed up the least backed up
one is tried first.
Also fix a hole in the selection spread. It was applied to the healthy
list only, so whenever no host was eligible that list was empty, the
shuffle was a no-op, and the held-back hosts were handed out in strict
score order - concurrent deployments agreeing on one host in exactly the
conditions that caused the pile-up. The spread now applies to whichever
tier leads, which also removes the special-cased branch it was hiding
in. The "short of capacity" warning stays narrow: hosts merely being
unmeasured, as they all are on a freshly started management server, is
not a capacity problem and must not warn on every deployment.
Signed-off-by: Brad House <bhouse@nexthop.ai>
0 commit comments