Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   "Benjamin Coddington" <bcodding@redhat.com>
To:     "Chuck Lever III" <chuck.lever@oracle.com>
Cc:     "Steve Dickson" <SteveD@RedHat.com>,
        "Linux NFS Mailing List" <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH v2 1/2] nfsuuid: a tool to create and persist nfs4 client
 uniquifiers
Date:   Fri, 11 Feb 2022 13:28:16 -0500
Message-ID: <D0908E76-C163-4DBF-A93C-665492EB9DB2@redhat.com>
In-Reply-To: <DDB59BD9-8C29-45C3-ABAF-B25EDDB63E09@oracle.com>
References: <cover.1644515977.git.bcodding@redhat.com>
 <9c046648bfd9c8260ec7bd37e0a93f7821e0842f.1644515977.git.bcodding@redhat.com>
 <7642FA55-F3F2-4813-86E2-1B65185E6B36@oracle.com>
 <3d2992df-7ef7-50ba-4f11-f4de588620d2@redhat.com>
 <DDB59BD9-8C29-45C3-ABAF-B25EDDB63E09@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Precedence: bulk

On 11 Feb 2022, at 10:48, Chuck Lever III wrote:

>> On Feb 11, 2022, at 8:44 AM, Steve Dickson <SteveD@RedHat.com> wrote:
>>
>> On 2/10/22 1:15 PM, Chuck Lever III wrote:
>>>> On Feb 10, 2022, at 1:01 PM, Benjamin Coddington 
>>>> <bcodding@redhat.com> wrote:
>>>>
>>>> The nfsuuid program will either create a new UUID from a random 
>>>> source or
>>>> derive it from /etc/machine-id, else it returns a UUID that has 
>>>> already
>>>> been written to /etc/nfsuuid or the file specified.  This small,
>>>> lightweight tool is suitable for execution by systemd-udev in rules 
>>>> to
>>>> populate the nfs4 client uniquifier.
>>> I like everything but the name. Without context, even if
>>> I read NFS protocol specifications, I have no idea what
>>> "nfsuuid" does.
>> man nfsuuid :-)
>
> Any time an administrator has to stop to read documentation
> is an unnecessary interruption in their flow of attention.
> It wastes their time.
>
>
>>> Possible alternatives:
>>> nfshostuniquifier
>>> nfsuniquehost
>>> nfshostuuid
>> I'm good with the name... short sweet and easy to type.
>
> I'll happily keep it short so it is readable and does not
> unnecessarily inflate the length of a line in a bash script.
> But almost no-one will ever type this command. Especially
> if they don't have to find its man page ;-p
>
> My last serious offers: nfsmachineid nfshostid
>
> I strongly prefer not having uuid in the name. A UUID is
> essentially a data type, it does not explain the purpose of
> the content.

How do you feel about these suggestions being misleading since the 
output is
not the nfs client's id?  Should we put that information in the man 
page?
Do sysadmins need to know that the output of this command is (if it is 
even
used at all) merely possibility of being a part of the client's id, the
other parts come from other places in the system: the hostname and 
possibly
the ip address?  That's my worry.  If we name it nfsmachineid or 
nfshostid,
do you feel like we ought to have it do the much more complicated job of
accurately outputting the actual client id?

Right now nfsuuid outputs uuids (or whatever was previously stored, up 
to 64
chars).  It generates uuids, like uuidgen.  Without something external 
to
itself (a udev rule, for example), it doesn't have any relationship to 
an
NFS client's id.  It could plausably be used in the future for other 
parts
of NFS to generate persitent uuids.  The only reason we don't just use
`uuidgen` is that we want to wrap it with some persistence.  A would a 
name
like stickyuuid be better?

Ben