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:     "Neil Brown" <neilb@suse.de>, "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:   Wed, 16 Feb 2022 14:01:32 -0500
Message-ID: <3AF29DC6-2EEB-4C3E-BD6C-BE31910921AE@redhat.com>
In-Reply-To: <42AAFEDD-F4EE-4A91-BD23-E08B1149EF1C@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>
 <948D8123-E310-4A35-BF04-C030F20EA83C@redhat.com>
 <164479707170.27779.15384523062754338136@noble.neil.brown.name>
 <863AB69A-D5D6-4F22-950C-E5F468CD4552@redhat.com>
 <42AAFEDD-F4EE-4A91-BD23-E08B1149EF1C@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Precedence: bulk

On 14 Feb 2022, at 10:39, Chuck Lever III wrote:

>> On Feb 14, 2022, at 6:15 AM, Benjamin Coddington 
>> <bcodding@redhat.com> wrote:
>>
>> On 13 Feb 2022, at 19:04, NeilBrown wrote:
>>
>>> On Sat, 12 Feb 2022, Benjamin Coddington wrote:
>>>> 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.
>>>>
>>>
>>> I agree.  This tool primarily does 1 thing - it sets a string which 
>>> will
>>> be the uniquifier using the the client_owner4.  So I think the word
>>> "set" should appear in the name.  I also think the name should start 
>>> "nfs".
>>> I don't much care whether it is
>>>  nfssetid
>>>  nfs-set-uuid
>>>  nfssetowner
>>>  nfssetuniquifier
>>>  nfssetidentity
>>>  nfsidset
>>> though perhaps I'd prefer
>>>  nfs=set=id
>>>
>>> If not given any args, it should probably print a usage message 
>>> rather
>>> than perform a default action, to reduce the number of holes in 
>>> feet.
>>>
>>> .... Naming  - THE hard problem of computer engineering ....
>>
>> No, it does NOT set the uniquifier string.  It returns it on stdout.  
>> If
>> you run it without args it just prints the string.  Its completely 
>> harmless.
>
> OK, my understanding was that if you run it as root, and the
> string isn't already set, it does indeed set a value in the
> persistence file.
>
> That should be harmless, though. Once it is set, it is always
> the same afterwards, and that's fine. Someone who just types
> in the command to see what it does can't damage their
> metatarsals; the worst that happens is the persistence file
> is never used again.
>
> I agree that's not very "set"-like.
>
>  nfsgetuniquifier
>  nfsguestuniquifier
>  nfsnsuniquifier
>  ns-uniquifier
>
> Use with copious amounts of tab completion.

Coming back to this.. so it seems at least part of our disagreement 
about
the name had to do with a misunderstanding of what the tool did.

Just to finally clear the air about it: the tool does not write to 
sysfs, it
doesn't try to modify the client in any way.  I'm going to leave it up 
to
the distros.

Considering this, I think your only remaining objection to "nfsuuid" is 
that it
might return data other than a uuid if someone points it at a file that
contains data other than a uuid.

I can fix that.  And its probably not a bad idea either.  The nfsuuid 
tool
can ensure that the persisted data is a uuid.

Maybe I also need to change the man page or description of the patch to 
be
clearer about what the tool does.  Any suggestions there?

Ben