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 16:06:20 -0500
Message-ID: <948D8123-E310-4A35-BF04-C030F20EA83C@redhat.com>
In-Reply-To: <06B01290-E375-455E-A6D7-419CA653A0D1@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>
 <D0908E76-C163-4DBF-A93C-665492EB9DB2@redhat.com>
 <E2C56D5B-AC77-48D1-9AF6-268406648657@oracle.com>
 <4657F9AE-3B9E-4992-9334-3FF1CF18EF31@redhat.com>
 <C7533D80-25B3-4722-94A9-0440C48B8574@oracle.com>
 <945849B4-BE30-434C-88E9-8E901AAFA638@redhat.com>
 <06B01290-E375-455E-A6D7-419CA653A0D1@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Precedence: bulk

On 11 Feb 2022, at 15:51, Chuck Lever III wrote:

>> On Feb 11, 2022, at 3:16 PM, Benjamin Coddington 
>> <bcodding@redhat.com> wrote:
>>
>> On 11 Feb 2022, at 15:00, Chuck Lever III wrote:
>>
>>>> On Feb 11, 2022, at 2:30 PM, Benjamin Coddington 
>>>> <bcodding@redhat.com> wrote:
>>>>
>>>> All the arguments for exacting tolerances on how it should be named 
>>>> apply
>>>> equally well to anything that implies its output will be used for 
>>>> nfs client
>>>> ids, or host ids.
>>>
>>> I completely disagree with this assessment.
>>
>> But how, and in what way?  The tool just generates uuids, and spits 
>> them
>> out, or it spits out whatever's in the file you specify, up to 64 
>> chars.  If
>> we can't have uuid in the name, how can we have NFS or machine-id or
>> host-id?
>
> We don't have a tool called "string" to get and set the DNS name of
> the local host. It's called "hostname".
>
> The purpose of the proposed tool is to persist a unique string to be
> used as part of an NFS client ID. I would like to name the tool based
> on that purpose, not based on the way the content of the persistent
> file happens to be arranged some of the time.
>
> When the tool generates the string, it just happens to be a UUID. It
> doesn't have to be. The tool could generate a digest of the boot time
> or the current time. In fact, one of those is usually part of certain
> types of a UUID anyway. The fact that it is a UUID is totally not
> relevant. We happen to use a UUID because it has certain global
> uniqueness properties. (By the way, perhaps the man page could mention
> that global uniqueness is important for this identifier. Anything with
> similar guaranteed global uniqueness could be used).
>
> You keep admitting that the tool can output something that isn't a
> UUID. Doesn't that make my argument for me: that the tool doesn't
> generate a UUID, it manages a persistent host identifier. Just like
> "hostname." Therefore "nfshostid". I really don't see how nfshostid
> is just as miserable as nfsuuid -- hence, I completely disagree
> that "all arguments ... apply equally well".

Yes - your arguement is a good one.   I wasn't clear enough admitting 
you
were right two emails ago, sorry about that.

However, I still feel the same argument applied to "nfshostid" 
disqualifies
it as well.  It doesn't output the nfshostid.  That, if it even contains 
the
part outputted, is more than what's written out.

In my experience with linux tools, nfshostid sounds like something I can 
use
to set or retrieve the identifier for an NFS host, and this little tool 
does
not do that.

> In fairness, I'm trying to understand why you want to stick with
> "nfsuuid". You originally said you wanted a generic tool. OK, but
> now you say you don't have other uses for the tool after all. You
> said you don't want it to be associated with an NFS client ID. That
> part I still don't grok. Can you help me understand?

I don't want to stick with nfsuuid, I'm just trying to apply everyone's
reasoning to the current list of suggested names and it appears to me
that we've disqualified them all.

>>> I object strongly to the name nfsuuid, and you seem to be 
>>> inflexible. This
>>> is not a hill I want to die on, however I reserve the right to say 
>>> "I told
>>> you so" when it turns out to be a poor choice.
>>
>> How does agreeing with you multiple times in my last response and 
>> making
>> further suggestions for names seem inflexible to you?  This is the 
>> worst
>> part of working over email - I think you're misreading my good humor 
>> in the
>> face of a drudging discussion as sarcasm or ill will.
>
> Nope, not at all. It wasn't apparent that you agreed, as much
> of your reply seemed to be disagreeing with my reply. So maybe
> I am overreacting. Though my reply can also be read with humor,
> even though it is a bit dry.

Sorry about that -- I really just want to move forward.  I can send it 
again
as nfshostid.  I think if we are clear in the man page that it isn't
necessarily part or any of the identifier used by NFS, rather its just
trying to manage the persistent unique portion, it works for me.

Unless we can go with persistychars, because that makes me grin.

Ben