Bluefin Server reports no stream identifier to countme

[castrojo]

What

elements/bluefin-server/os-image-info.bst declares only:

{ "image-name": "server" }

No image-tag, no image-flavor. The shared reporter omits fields it is not given, so pings from this image arrive with neither, and the service records tag=unknown.

Why it is currently correct

Every other image in the family is an OCI image with a promotion stream — stable, testing, latest — and reports the tag it is following, resolved through bootc. This image is a DDI delivered by systemd-sysupdate. It has no container tag, and os-release carries NAME="Bluefin Server" / ID=flatcar, neither of which is a stream.

Sending a placeholder would be worse than sending nothing: a made-up stable is indistinguishable from a real one in the data.

The question

Does this image have a promotion stream worth counting separately, and if so what identifies it?

Candidates:

• The sysupdate channel, if one is configured per build.
• %{flatcar-version} from include/flatcar.yml, though that is a kernel/sysext version rather than a stream.
• Nothing, and tag=unknown is the honest answer permanently.

What fixed looks like

Either a decision that no stream exists and this closes as intended behaviour, or a stream identifier added to os-image-info.bst so counts can be split by it.

Impact

Counts by image are unaffected — server aggregates correctly either way. Only per-stream breakdown is missing.

[castrojo]

Answered by the transfer definitions, which are the source of truth for what this image follows:

# files/os/sysupdate.d/50-root.transfer
[Source]
Path=https://github.com/projectbluefin/server/releases/latest/download/
MatchPattern=bluefin-server-ddi-@v.raw.zst

60-uki.transfer uses the same Path.

Revision to the framing above

The issue asked whether a stream exists. It does — there is exactly one, and it is named latest. That is different from having none.

tag in the countme protocol answers "which promotion stream am I following." OCI images resolve it from bootc and report stable, testing or latest. This image follows GitHub releases latest. Same question, same kind of answer, so tag=latest is truthful rather than a placeholder — and it makes the image comparable: server:latest alongside bluefin:stable and dakota:latest, instead of an unknown bucket that means nothing.

Recommendation

Derive the channel from the transfer Path rather than hardcoding it in os-image-info.bst. The last path segment before download/ is the channel. If a stable/testing split is ever introduced, counting follows it automatically instead of continuing to report latest for everything.

What not to do

Do not report the DDI version as tag. @v is a version, not a stream. Putting it there breaks comparability with every other image and answers a different question — update lag rather than stream adoption. Version adoption is worth measuring, but as its own field.

Trap worth recording

VERSION_ID is not this image's version. os-release-flatcar.bst sets VERSION_ID=${FLATCAR_VERSION}, which is the Flatcar kernel release (4593.2.5), not the DDI. Anything reaching for VERSION_ID to identify the image reports the kernel and looks plausible while being wrong. Related: #88.