BMC — power and console

BMC control is for the case where a node stops answering. The agent is gone, SSH is gone, and the only thing left is whatever management hardware sits beside the machine rather than on it. Rasputin drives that hardware directly, so a wedged node is a button in the dashboard instead of a walk to the rack.

Because it is a different piece of hardware on every cluster board, what it can do varies. Rasputin does not paper over that.

What controls you get

Each node’s panel shows only the controls its management hardware can honour:

A control that your hardware cannot honour is not rendered. That is deliberate: a button that fails on click is worse than an absent one, because it costs you a diagnosis during an outage. If you don’t see CONSOLE on a board, the table below says why.

Supported management hardware

Other hardware is not supported yet. Rasputin is pre-alpha and the list is short on purpose — each entry is a driver we run on our own bench, not a spec we read.

Why the Turing Pi has no console

The Turing Pi’s BMC does expose the nodes’ serial ports, so this looks like something we skipped. It isn’t. We built the driver, ran it on the board, and found its serial interface is shaped for a different job than the one Rasputin’s console does.

The board’s UART access is request-based: you ask for the output that has accumulated since last time, and you send input a line at a time. That’s a good fit for scripting and for checking in on a node — it’s what tpi uart is built on, and it does that job well. What it isn’t is a continuous stream. There’s no per-keystroke channel, so no Ctrl-C, arrow keys or ANSI; and because output collects in a fixed buffer between requests, a burst longer than the buffer can roll over before the next read picks it up.

Rasputin’s console is pointed at one case in particular: watching a node boot when nothing else about it is working. That wants an uninterrupted stream, since the line you need is usually the one you didn’t know to wait for. Built on periodic reads, it would be fine most of the time and patchy during exactly the fast console output you were trying to catch — and those gaps would look like our bug rather than the shape of the interface underneath.

So we don’t offer one here. Power and restart work fully on a Turing Pi; console is absent on purpose, and the dashboard shows you that rather than a button that disappoints.

If you want a serial console on a Turing Pi, the board already has one — tpi uart, or the console in the Turing Pi BMC web interface. It’s built for that interface and does it properly, so we’d rather send you there than ship a second-best version of it.

Why this varies at all

Rasputin models BMC ability per node, not per cluster: each management host tells the control plane which nodes it reaches and what it can do for each one. Power, restart and console are advertised separately, and a console additionally declares its fidelity, so a line-oriented or lossy console can be labelled instead of quietly disappointing you.

That is what lets very different hardware sit behind one dashboard honestly — a serial control bus and a REST API over the network already look nothing alike, and the boards we haven’t met yet will differ again. The interface stays the same; the claims stay true to whatever is actually underneath.