Re: How should the nvme-cli package generate its host "NQN"?
On Fri, Sep 28, 2018 at 11:42:58AM -0700, Andrew Lutomirski wrote:
There's a request for the nvme-cli package to generate a unique
name
to use when connecting to NVMe-over-fabrics targets:
https://bugzilla.redhat.com/show_bug.cgi?id=1633814
I'm wondering what the right approach is. For the various Atomic
variants, ISTM it's not very nice for the package to generate files in
/etc in a postinstall script. And it also seems like it might be
surprising for a remove-and-reinstall of nvme-cli to generate a whole
new NQN.
So this is similar to /etc/iscsi/initiatorname.iscsi. This one is
generated in %post by using iscsi-iname binary:
https://src.fedoraproject.org/rpms/iscsi-initiator-utils/blob/master/f/is...
But I wouldn't use this method verbatim! iscsi-iname generates different ID on
every invocation, which is not nice.
The way proposed in BZ use very similar mechanism for NVMoF, invoking
nvme gen-hostnqn. Which has the same problem: every invocation gives
random, non-persistent ID. Again, not nice.
I propose changing the mechanism of generating the name to give
persistent, machine-specific result. The best way would be to
patch nvme gen-hostqn to use sd_id128_get_machine_app_specific()
function. This way generated hostqn will be tied to machine-id.
After this change, stable hostqn could be generated at any moment:
during boot, during package installation, from udev-rule, etc…
At the moment nvme gen-hostqn is not idempotent. Proposed change
would make the issue of unique name easier.
--
Tomasz Torcz "Never underestimate the bandwidth of a station
xmpp: zdzichubg(a)chrome.pl wagon filled with backup tapes." -- Jim Gray