feat(baremetal): send a server's logs somewhere, from the terminal

[Denis-hamon]

What this is

Seven v2 routes send a dedicated server's logs to a Log Data Platform stream. None of them was reachable from this CLI — not skipped, invisible: the repository could only fetch v1 schemas, so the surface never appeared in any inventory. #262 gives it a refresh target; this wires the commands.

ovhcloud baremetal logs kinds <server>
ovhcloud baremetal logs url <server> [--kind]
ovhcloud baremetal logs subscription list <server> [--kind]
ovhcloud baremetal logs subscription get <server> <id>
ovhcloud baremetal logs subscribe <server> --stream <title|id> [--kind] [--wait] [--yes|--dry-run]
ovhcloud baremetal logs unsubscribe <server> <id> [--wait] [--yes|--dry-run]

Every one of these operations is badged Alpha version upstream.

What the measurement changed in the design

Measured against a real account on 20 August 2026, before any of this was written.

It is not a tail, so it is not called one. POST .../log/url returns a signed https://get.logs.ovh.com/search address into the Log Data Platform search interface — not a socket, not a chunked stream. It is valid for exactly thirty minutes. The command is logs url, it prints the link, and it says when the link dies and that it carries its own authorisation. A command called tail that printed a web address would be lying in its own name.

There is one kind of log, and --kind is still optional both ways. install — the operating system installation logs, on 8 servers out of 8. Requiring an operator to type the only possible value is friction; defaulting to the string "install" in Go would keep reaching that one kind on the day a second appears. So the flag is left empty by default and the server is asked: one kind is taken silently, several are refused with their names, none is reported as an answer rather than an error.

The subscription carries its own Log Data Platform service. A subscription object is {subscriptionId, kind, streamId, serviceName, resource} where serviceName is the LDP service, not the server. The POST answers {operationId, serviceName} for the same reason, so --wait is told where to poll and needs no lookup of its own.

The stream resolution is the command

An operator has a server name and wants "my logs, over there". They do not have a stream UUID. This account carries 25 LDP services and 59 streams, one service holding 21 on its own, with titles like Prestashop nginx logs (filebeat) and datastream_test.

--stream therefore takes a title or an identifier. Same three-case shape as vrack attach resolving a server to its vRack interface (#249) and baremetal traffic resolving it to its network controllers (#254):

$ ovhcloud baremetal logs subscribe ns3118333.ip-51-68-100.eu --stream test_iplb --dry-run
🛑 2 streams are called "test_iplb", on different Log Data Platform services.
   Name the one you mean by its identifier:
     1e66c04a-040d-4fac-af46-ba79077a00ce  (service ldp-ay-10969)
     55033697-8afa-4f5b-8fd1-3f9ba129a312  (service ldp-hf-26139)

That refusal is not defensive: three titles on this account are carried by two streams each (test_iplb, test, Stream1). And the account holds both Test and test, so the match is case-sensitive — folding case would silently pick one of two different streams.

A miss says what does exist, capped and counted rather than truncated in silence:

🛑 no stream is called "Stream". Close to: "Data-Stream-Pierrick-PCC" (service ldp-pu-66281),
   "My first data stream" (service ldp-wq-88992), "Stream 2" (service ldp-qz-47460),
   "Stream1" (service ldp-qz-47460), "Stream1" (service ldp-tg-34397), and 3 more.
   List them with: ovhcloud ldp list

The sweep is 85 requests and 2.15 seconds, and none of it is cached. A stale identifier resolved from a cache would send a machine's logs to the wrong place — the same reason #249 removed a cached name from a confirmation prompt. Only the shell-completion suggestions are cached, where staleness costs a suggestion.

--wait crosses both catalogues, and reads the state afterwards

The change is made against the server on /v2 and returns an operation identifier, and no v2 route can follow it. It is followed on GET /v1/dbaas/logs/{ldpService}/operation/{id}, whose dbaas.logs.OperationStateEnum — FAILURE, PENDING, RECEIVED, RETRY, REVOKED, RUNNING, STARTED, SUCCESS — is a sixth status vocabulary in this repository and shares nothing with the five already here.

And as everywhere in this series, the operation reporting SUCCESS is not the subscription existing. The operation object carries subscriptionId, so the wait is handed the identifier to read the state back with; the removal checks the other way, that the subscription is actually gone.

Two traps avoided by name

The --kind filter belongs to the collection call. The expansion builds one URL per subscription as path + "/%s", so a query string carried over would produce .../log/subscription?kind=install/<id> — a route that does not exist, for a filter that would have looked like it worked. Same class as the --filter ordering trap of #256 and the ticket filters of #261. A test asserts no requested URL contains kind=install/.

The dry run shows the body. common.ReportDryRun prints the method and the path, which is the whole story for the DELETE and half of it for the two POSTs: what an operator checks before agreeing to a subscription is which stream and which kind, and neither is in the URL. Built as one document rather than two messages, because under -o json two messages are two JSON documents on one stdout — the reason baremetal ticket does the same.

Verified against the API

Full cycle on ns3118333.ip-51-68-100.eu, against a stream its owner had already named TO REMOVE 1:

step	measured
state before, read outside the CLI	[]
subscribe --stream "TO REMOVE 1" --wait --yes	7 s, exit 0, title resolved to 69813166-… on ldp-nx-19421
read back outside the CLI	the subscription is there
unsubscribe --wait --yes	6 s, exit 0
state after, read outside the CLI	[] — back to the start
removing the same id again	refused, with the command that lists

Reads exercised against the real API too: logs kinds (one kind, its display name and its four extra fields), logs url (a live 30-minute link), logs subscription list on the one server on this account that already had a subscription, and the --kind filter both matching and not.

Refusals executed against the real API: ambiguous title, near-miss title, unknown title, no --yes on a non-interactive stream, and --dry-run on both writes.

Gate

go build, go vet, make wasm, go test ./..., docgen — all clean.

20 tests (6 unit, 14 cobra) and 12 sabotages, 12 red — each on the test it was meant to exercise, with restoration checked by digest.

One of the twelve first came back red for the wrong reason: it broke the build instead of the test, which proves nothing about the test's teeth. Re-aimed so it compiles and the read-back test is what falls. The count above is the corrected run.

Stacked on #262, which is stacked on #261.

What this does not do

• baremetal list --tag, which the same v2 schema makes possible via the iamTags filter, is left to its own change: it alters a command everybody already uses, and that deserves its own diff.
• The v2 schema is embedded whole rather than curated. All seven of its paths are either used here or are the two server routes; there is no subset to pick.

[Denis-hamon]

Human review — Doubt

K1 · logs url, not logs tail
Dimension: Naming

Expected: The name does not promise a stream. A tail that is not one would be a command lying in its own name.

est ce qu'il y' a bien Log data platform installé sur ce serveur ?

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

[Denis-hamon]

Answering the doubt on K1: "est-ce qu'il y a bien Log data platform installé sur ce serveur ?"

No, and logs url does not need it. Measured on the test machine on 24/08:

• baremetal logs kinds returns exactly one kind, install — Operating system installation logs;
• baremetal logs subscription list returns zero subscriptions.

logs url reads the install logs OVHcloud hosts itself, and returns a signed get.logs.ovh.com/search address valid for thirty minutes. Log Data Platform only enters the picture with logs subscribe, which is the next check in this area — a subscription sends the same logs to an LDP stream you own.

So the naming question stands on its own: the route hands back a search page, not a socket, and url says that where tail would not. The sandbox's protocol for this check now starts with logs kinds, which is a plain read and answers the question without leaving the page.

[Denis-hamon]

Human review — Doubt

K2 · Is the expiry stated?
Dimension: Product fit

Expected: The expiry date is printed, and it is stated that the link carries its own authorisation.

Find in the test a server with Log already settled

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

[Denis-hamon]

Human review — Doubt

K1 · logs url, not logs tail
Dimension: Naming

Expected: The name does not promise a stream. A tail that is not one would be a command lying in its own name.

Find in the test a server with Log already settled

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

[Denis-hamon]

Human review — Doubt

K3 · You give a stream title, not a UUID
Dimension: Discoverability

Expected: --stream accepts a title. Resolution costs 85 requests in 2.15s and nothing is cached: a stale identifier would send a machine's logs to the wrong place.

no stream is called "prod nginx". This account has 59 of them.
Complete them with: ovhcloud baremetal logs subscribe --stream

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

[Denis-hamon]

Human review — Doubt

K4 · Ambiguous title: refusal or silent pick?
Dimension: Error message

Expected: A refusal listing the candidates with their LDP service. Matching is case sensitive.

🛑 2 streams are called "test", on different Log Data Platform services.
Name the one you mean by its identifier:
5e0256d4-d9c5-4575-9cbc-24ea170b0c49 (service ldp-mj-88337)
42534b63-00d3-4087-9e7d-3fab501909f3 (service ldp-tg-34397)

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