Skip to content

Embed sush in sled-agent - #11252

Draft
plotnick wants to merge 1 commit into
mainfrom
sush-sled-agent
Draft

Embed sush in sled-agent#11252
plotnick wants to merge 1 commit into
mainfrom
sush-sled-agent

Conversation

@plotnick

@plotnick plotnick commented Sep 6, 2026

Copy link
Copy Markdown
Contributor

This begins the integration of the Support Shell (RFD 620) service into the wider control plane, starting with sled-agent. Replaces initial integration attempt #11034.

Sled-agent now builds the sush job manager during bootstrap as a long-running task and serves its HTTP API on the bootstrap network from the start. Once the sled has an underlay address, it serves the same API there, too.

In addition to its client-facing API, sush also gossips sessions, jobs, and events over sprockets on the bootstrap network using rumors. Gossip peers are discovered using the bootstore's existing DDM polling loop, and a map polled from MGS resolves job targets given as cubby numbers.

The records sush must trust across reboots (its gossip identity and its execution boundary) live on the M.2s' cluster datasets. Job output is recorded on the ramdisk until an encrypted debug dataset is mounted, then moves there with a raised size limit. The signatures on all jobs must chain to one of the configured certs; the cert here is a sandbox root which must be replaced with a production cert before shipping (see oxidecomputer/sush#46).

This begins the integration of the [Support Shell](https://github.com/oxidecomputer/sush)
([RFD 620](https://rfd.shared.oxide.computer/rfd/0620))
service into the wider control plane, starting with sled-agent.

Sled-agent now builds the sush job manager during bootstrap as a
long-running task and serves its HTTP API on the bootstrap network
from the start. Once the sled has an underlay address, it serves
the same API there, too.

In addition to its client-facing API, sush also gossips sessions,
jobs, and events over sprockets on the bootstrap network using
[rumors](https://github.com/oxidecomputer/rumors). Gossip peers
are discovered using the bootstore's existing DDM polling loop,
and a map polled from MGS resolves job targets given as cubby numbers.

The records sush must trust across reboots (its gossip identity and
its execution boundary) live on the M.2s' cluster datasets. Job output
is recorded on the ramdisk until an encrypted debug dataset is mounted,
then moves there with a raised size limit. The signatures on all jobs
must chain to one of the configured certs; the cert here is a sandbox
root which **must be replaced with a production cert before shipping**
(see oxidecomputer/sush#46).

Co-Authored-By: Claude Mythos 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant