RFC: NVMe-oF orchestrator coexistence — nvme-discoverd, ownership registry, and exclusion list

[martin-belanger]

As NVMe-oF deployments grow, hosts increasingly run multiple tools that manage NVMe-oF connections — nvme-stas, dracut/initramfs scripts, and soon a new daemon nvme-discoverd. Without coordination these tools can conflict: one orchestrator may disconnect a controller another is actively managing, or connect to a controller another has deliberately excluded.

This discussion covers a proposed set of four RFCs that address orchestrator coexistence:

• rfc-nvme-orchestrator-coexistence — frames the problem, defines the orchestrator hierarchy, shows how the pieces fit together
• rfc-nvme-registry — a lightweight ownership registry in /run/nvme/registry/ so orchestrators can declare ownership and disconnect-all avoids stepping on live connections (implementation PR: libnvmf: NVMe Controller Ownership Registry (V2) #3425)
• rfc-nvme-exclusion — a human-administered exclusion list at /etc/nvme/exclusions/ to prevent orchestrators from auto-connecting to controllers the admin wants excluded
• rfc-nvme-discoverd — a new connect-only daemon that manages NBFT boot controllers, FC-discovered controllers, and statically configured controllers, using systemd transient units for per-controller lifecycle management

The full documents are in PR #3442 (DO-NOT-MERGE) where you can leave inline comments on specific sections.

High-level feedback here is very welcome — especially on whether the overall architecture fits how you see these tools being used in practice.

[martin-belanger]

cc: @igaw @mwilck @tbzatek @MichaelRabek — would appreciate your feedback on the proposed architecture, either here for high-level discussion or as inline comments on PR #3442.

[tbzatek]

+ Cc: @johnmeneghini