Skip to content
dockmesh

Drain Host

Draining a host migrates all of its stacks to other hosts in a safe order, then marks the host as unschedulable. Use it before kernel updates, hardware maintenance, or retiring a host permanently.

Starting a drain

Section titled “Starting a drain”
  1. Open Hosts in the sidebar and click into the host you want to evacuate
  2. Click Drain in the header — opens the modal with the planner’s proposed placement
  3. Review what’s about to move, then Execute drain

The planner is automatic: it sorts stacks largest-first (rough 500 MB-per-stack estimate as proxy weight) and greedily bin-packs them onto the other online hosts, picking the one with the most free space for each stack. You don’t pick destinations per stack and there’s no UI choice between ordering strategies — what the planner shows in the modal is what runs.

Each stack goes through the standard Migration pre-flight before its move begins. If pre-flight fails for a stack, the drain skips it and continues with the rest.

During the drain

Section titled “During the drain”

The host detail page shows a live progress view:

  • Current stack being migrated
  • Queued stacks with their predicted destination
  • Per-stack status (planning / executing / completed / failed)
  • Pause / Resume / Abort controls on the drain itself

The drain runs through the states planning → executing → completed (or aborted if you stop it). Failed stacks are skipped with a reason in the per-stack status; the drain continues with the rest. At the end you have a summary showing what succeeded and what didn’t.

After the drain

Section titled “After the drain”

Drained stacks are not automatically migrated back when the host returns from maintenance. If you want them back, run Migration per stack from the destination back to the original host, or leave them where they ended up — the new placement is usually as valid as the old one.

There is no separate cordon/uncordon mechanism today. Marking a host as “no new workloads” without moving existing ones isn’t shipped — track that decision in your runbook or block scheduling at the firewall during maintenance.

Audit log

Section titled “Audit log”

Every drain event — started, per-stack migration, completed, failed — is written to the audit log with user, timestamp, source, destination, and outcome.

See also

Section titled “See also”