oxidecomputer / oxidecomputer/omicron

ensure that capacity exists to evacuate sleds for live upgrade

Open
#2,944 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

customer
Dominant language
Rust
Stars
572
Forks
97
Avg merge
2d 12h
Merged PRs (30d)
96

Description

Upgrading a sled requires it to be vacated of instances and services. This requires that, at any time,

  • A rack must always have enough aggregate free capacity to arrange to hold the contents of any individual sled, and
  • For any sled S, it must always be possible to arrange the workloads on other sleds in the rack so that there is an acceptable destination for each workload running on S. (In other words, the available space can't become fragmented such that there's a sled's worth of space in aggregate, but there's no way to gather the free space onto a single sled to allow a large workload to land there.)

(All this applies equally to multi-rack deployments; the important thing is that if a workload can land in some domain, there must be enough possibly-contiguous capacity to empty a sled in that domain.)

If these properties don't hold, users or operators will have to stop workloads to take a sled out of service. We would prefer to avoid this, at least in cases where all sleds are operating normally and nothing has failed.

Instance provisioning doesn't currently guarantee either property. It only ensures that an instance will land on a sled that has space available for it without taking global usage into account. Even if Nexus did track domain-wide resource usage, we would have to discover and implement a bin-packing scheme that preserves our fragmentation properties. That seems difficult, though maybe this is a solved problem whose solution I don't know.

In the short term, it may be simplest to address this by allowing a sled to be put into a state where it's only eligible to receive migratory workloads and suggesting that operators use this mechanism to keep a sled in reserve for updates.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing instance provisioning in Nexus and how sled eligibility and workload placement are represented. Define how the system would preserve enough aggregate and gatherable capacity to evacuate any sled, or specify the proposed reserve-sled mechanism; done means live upgrades do not require stopping workloads when all sleds are healthy.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
backend, distributed-systems
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.