feat(baremetal): make the storage block of a reinstall discoverable

[Denis-hamon]

Stacked on #249 — only the last commit (201de18) belongs to this PR.

Partitioning was not blocked

The audit this work follows lists partitioning as the costliest case of "the CLI exposes only the fields mapped to flags". Measured against the live API, that premise is wrong: --from-file carries the whole storage block — hardware RAID, layout, LVM and ZFS extras — untouched into the request body. --dry-run shows it going out verbatim. And the sample this CLI ships already contains a full partitioning layout.

So this adds no partitioning flags. storage is an array of objects each holding an array of partitions with five fields; expressing that as flags is how a CLI becomes unusable. The file is the right instrument and it already works.

What was missing is every way of finding out what to put in it. On a reinstall, finding out at install time means the disks are already wiped.

ovhcloud baremetal list-partition-schemes <server> --os <template>
ovhcloud baremetal raid-profile <server>

Two commands, and one deliberately absent

list-partition-schemes is asked per template, because that is what the answer depends on — hence --os is required rather than silently defaulted.

raid-profile answers the question you must answer before writing a hardwareRaid block. All fourteen servers checked on a real account have no controller, and the API says so with a 403:

$ ovhcloud baremetal raid-profile ns30704xx…
ns30704xx… has no hardware RAID controller.
Use software RAID instead: set `raidLevel` on the partitions of the storage layout.

That is an answer, not a failure, so it is reported as one — while any other error stays an error, and there is a test for each.

There is no command for sizing a RAID configuration, on purpose. install/hardwareRaidSize is in the embedded schema and badged "Stable production version". It does not exist:

request	result
hardwareRaidSize with both required params	404 Got an invalid (or empty) URL
… with one param, or none	404, same
… on 4 different servers, v1 and v2	404, same
hardwareRaidProfile, same servers (control)	403 with a business message

A routing 404 next to a sibling that resolves means the route is not served. A command for it would have failed every single time it ran. Worth reporting to whoever owns that schema.

The discovery path itself was broken

--init-file is how somebody writing a script obtains the example that documents the request body. It always opened a picker, which needs a terminal — so in exactly the scripted context it serves it failed with could not open a new TTY and wrote nothing.

Outside a terminal it now writes one example and says which: the "default" one this CLI ships, since for a reinstall that is the only one carrying a storage block; otherwise the first by name, sorted, because the examples are a map and ranging over it would write a different file on each run.

The whole loop now runs unattended:

baremetal list-compatible-os        → which templates
baremetal list-partition-schemes    → which schemes for that template
baremetal raid-profile              → hardware RAID, or software RAID instead
baremetal reinstall --init-file     → the skeleton, storage block included
baremetal reinstall --from-file --dry-run → exactly what would be sent

Two findings worth carrying beyond this PR

• --init-file runs in a PreRun ending with os.Exit(0), and that exit is load-bearing: without it the command would continue into Run, so --init-file on a reinstall would reinstall the server. It is not a testability wart to remove.
• display.OutputWarning terminates the process — it sets Warning, which reaches ExitFunc(0). The first version of this fix printed its message and never wrote the file. Anything after an OutputWarning is dead code, the same way it is after OutputError.

Seven tests. Four sabotages, four failures; two more did not compile and were discarded rather than counted.

doc/ovhcloud_logout.md remains untracked and unseen by the doc gate — git diff --exit-code does not look at untracked files. Not this change's business, but the hole is still there.

🤖 Generated with Claude Code

[Denis-hamon]

Human review — Doubt

C5 · Finding a partition scheme without reading the docs
Dimension: Discoverability

Expected: The sequence “which schemes does this template accept” then “write me an example” is guessable. Outside a terminal, --init-file writes a file and says which.

┌─────────┬─────────────┐
│ name │ template │
├─────────┼─────────────┤
│ default │ debian12_64 │
└─────────┴─────────────┘
exit 0

— Denis (Product Manager), through CLI sandbox review page

[Denis-hamon]

Answering the doubt on C5.

The single row is genuine, not a truncated list: that server accepts exactly one partition scheme for debian12_64, and the API returns one. The check is about the sequence being guessable — "which schemes does this template accept", then "write me an example" — rather than about the number of rows, so a one-row answer does not weaken it.

One thing did change underneath, in #241: an empty or near-empty table used to print its headers with no padding at all, because only data cells carried it. That is fixed, so a short table now reads the same as a long one.

[Denis-hamon]

Human review — Doubt

C5 · Finding a partition scheme without reading the docs
Dimension: Discoverability

Expected: The sequence “which schemes does this template accept” then “write me an example” is guessable. Outside a terminal, --init-file writes a file and says which.

┌─────────┬─────────────┐
│ name │ template │
├─────────┼─────────────┤
│ default │ debian12_64 │
└─────────┴─────────────┘
exit 0

— Denis (Product Manager), through CLI sandbox review page