feat(baremetal): ask what the machine will take, instead of making you guess

[Denis-hamon]

Stacked on #253 — only the last commit belongs to this PR.

Opened against #274, which asks for "an easy to use ergonomic wizard that knows most of the dynamic business rules" for OS reinstallation.

The rules are dynamic because the answers depend on each other

#250 added the two commands that answer the questions: which partition schemes a template allows, and whether the machine has a RAID controller. What it could not fix is that they have to be chained by hand:

ovhcloud baremetal list-compatible-os ns1234.ip-11.22.33.net     # 34 lines
ovhcloud baremetal list-partition-schemes ns1234… --os debian12_64
ovhcloud baremetal raid-profile ns1234…
ovhcloud baremetal reinstall ns1234… --os debian12_64 --from-file layout.json

Four commands, three of them clerical, and the second cannot be typed before the first is read — the schemes are a property of the template. All of it has to happen before the reinstall: finding out at install time means the disks are already wiped.

ovhcloud baremetal reinstall ns1234.ip-11.22.33.net --wizard

Each list is fetched for the answer just given. The result is handed to the reinstall that was already there: same confirmation (type the server name), same --dry-run, same --wait with the per-step progress from #253.

What it knows, and where each rule comes from

Measured on the test account, 8 servers, 25/08:

what was measured	result
templates per server	31 to 37, all ovh, no personal ones
partition schemes per template	exactly one, default, every time
hardware RAID controllers	none — 403 on all of them

Three behaviours come straight out of those numbers:

• A question with one possible answer is not a question. The scheme is settled and stated, not asked. Asking would add a keystroke and no information — but the value goes into the request, so it is printed rather than hidden.
• A personal template is labelled, not merged. The two name spaces overlap; picking the wrong mine_64 installs the wrong system.
• Nothing invents a hardwareRaid block. With no controller it is illegal; with one, the CLI still cannot size a configuration, because install/hardwareRaidSize is in the schema, badged "Stable production version", and answers 404 on every server tried (see the note in install.go from feat(baremetal): make the storage block of a reinstall discoverable #250). The wizard says which of the two situations you are in and points at --from-file, which already carries the whole storage block untouched.

Only partitioning.schemeName is modelled in Go. The rest of that block — disk groups, layouts, LVM and ZFS extras — stays where it belongs, in a file: expressing an array of partition objects as flags is how a CLI becomes unusable.

A wizard with nobody at the keyboard

--wizard in a pipeline would draw an alternate screen over the logs and wait for an answer that cannot come. It refuses instead, before touching the API, and names what to use in its place:

$ cat params.json | ovhcloud baremetal reinstall ns1234… --wizard
🛑 --wizard has questions to ask and there is no terminal to ask them on;
   pass --os, and --from-file for the storage layout

It is mutually exclusive with --from-file and --editor, which settle the same fields — otherwise the last writer would win in silence.

Run end to end, on a real server

$ ovhcloud baremetal reinstall ns3016406.ip-51-254-45.eu --wizard --dry-run

  Which OS should ns3016406.ip-51-254-45.eu be reinstalled with?

  > 1. alma10_64
    2. alma8-cpanel-latest_64
    3. alma8-plesk18_64
    ...
    ↑/k up • ↓/j down • q quit • ? more

  alma10_64 selected.

ℹ️  Partitioning scheme: default — the only one alma10_64 allows here.
ℹ️  ns3016406.ip-51-254-45.eu has no hardware RAID controller: software RAID
    goes in the partitioning layout, via --from-file.
Reinstalling ns3016406.ip-51-254-45.eu with alma10_64, partitioning scheme default.
🔍 Dry run: nothing was sent. This would have been posted to
   /v1/dedicated/server/ns3016406.ip-51-254-45.eu/reinstall:
{
  "operatingSystem": "alma10_64",
  "storage": [
    {
      "partitioning": {
        "schemeName": "default"
      }
    }
  ]
}

Exit 0, and the 32 entries in that list are what the API answered for that machine at that moment. The non-interactive refusal was run the same way: right message, exit 1.

Tests

Twelve, and each one was sabotage-checked: asking for the schemes without the template, asking a one-answer question, merging the personal templates into the OVH list, turning the RAID 403 into a blocking error, and removing the terminal guard each turn exactly one test red, and the right one.

The picker and the terminal check are two package-level variables so the wizard can be driven from a test at all — every other selector in this CLI calls display.RunGenericChoicePicker directly and is therefore untestable.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Improvement (improvement of existing commands)
• Breaking change (fix or feature that can break a current behavior)
• Documentation update