Design how to handle Systems without a SystemUUID (Discovery/metalprobe registry flow)

Summary

PR #630 introduces support for empty systemUUID on Server/System resources by generating a deterministic pseudo-UUID derived from the system serial number. This raised a follow-up design question about how the rest of the discovery/registration flow should behave for systems that do not report a native Redfish system UUID.

Background

During Discovery boot, the metalprobe agent posts host data back to /registry/{systemUUID}. In the current implementation (per PR #630 discussion), the ignition template's probeFlags always include a UUID value — either the real Redfish system UUID or the generated pseudo-UUID — so metalprobe posts using whichever UUID is present in probeFlags.

While this makes the immediate discovery flow work, it was flagged that we should explicitly design/document how the rest of the system (registry lookups, reconciliation, BMC/Server matching, re-registration, UUID collisions, etc.) should behave for Systems that lack a native SystemUUID, rather than relying solely on the pseudo-UUID as an implicit workaround.

Discussion

From PR #630:

• afritzler asked how Discovery boot via metalprobe is affected, since metalprobe posts host data to /registry/{systemUUID}.
• xkonni clarified that the ignition template's probeFlags always include the UUID (real or generated pseudo-UUID), so this specific post continues to work.
• afritzler requested a follow-up issue to design the broader handling of Systems without a SystemUUID.

Affected areas

• internal/controller/server_controller.go (generatePseudoUUID, patchServerURI)
• bmc/redfish.go (getSystemFromUri readiness semantics)
• Discovery/registry flow involving metalprobe and /registry/{systemUUID}
• Related issue: #612

Suggested scope of design work

• Confirm long-term behavior for registry lookups keyed by pseudo-UUID vs. real UUID.
• Consider edge cases: serial number changes/reuse, duplicate/missing serials, collisions between pseudo-UUIDs.
• Decide whether pseudo-UUID generation logic and its guarantees should be documented as part of the public API contract.
• Evaluate reconciliation/matching logic across BMC, Server, and metalprobe registry entries when only a pseudo-UUID is available.

Acceptance criteria

• A documented design/decision on how systems without a native SystemUUID are handled end-to-end (discovery, registry, reconciliation).
• Any necessary follow-up implementation tasks identified and tracked.

References

• PR: https://github.com/ironcore-dev/metal-operator/pull/630
• Discussion comment: https://github.com/ironcore-dev/metal-operator/pull/630#issuecomment (see thread between afritzler and xkonni on Discovery/metalprobe registry behavior)
• Requested by: @afritzler

Start by reading internal/controller/server_controller.go, especially generatePseudoUUID and patchServerURI, then inspect bmc/redfish.go and the discovery registry flow around metalprobe and /registry/{systemUUID}. Trace how pseudo-UUIDs are used for lookup, reconciliation, and re-registration. Done means a documented end-to-end decision covering the listed edge cases, with follow-up implementation tasks identified.