Linux NFS development
 help / color / mirror / Atom feed
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: [nfs-utils PATCH] nfs4id: a tool to create and persist nfs4 client uniquifiers
Date: Thu, 10 Feb 2022 10:47:24 -0500	[thread overview]
Message-ID: <E0B72831-1575-41CC-BB61-752F9CD0367C@redhat.com> (raw)
In-Reply-To: <10D2854A-310D-44DD-A31D-83385AD7D87C@oracle.com>

On 10 Feb 2022, at 10:21, Chuck Lever III wrote:

>> On Feb 10, 2022, at 8:28 AM, Benjamin Coddington 
>> <bcodding@redhat.com> wrote:
>>
>> On 8 Feb 2022, at 17:39, Steve Dickson wrote:
>>
>>> On 2/8/22 4:18 PM, Chuck Lever III wrote:
>>>>
>>>>
>>>>> On Feb 8, 2022, at 2:29 PM, Steve Dickson <steved@redhat.com> 
>>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 2/8/22 11:21 AM, Chuck Lever III wrote:
>>>>>>> On Feb 8, 2022, at 11:04 AM, Steve Dickson <steved@redhat.com> 
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> On 2/4/22 7:56 AM, Benjamin Coddington wrote:
>>>>>>>> The nfs4id 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/nfs4-id.  This small, lightweight tool is 
>>>>>>>> suitable for
>>>>>>>> execution by systemd-udev in rules to populate the nfs4 client 
>>>>>>>> uniquifier.
>>>>>>>> Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
>>>>>>>> ---
>>>>>>>>  .gitignore               |   1 +
>>>>>>>>  configure.ac             |   4 +
>>>>>>>>  tools/Makefile.am        |   1 +
>>>>>>>>  tools/nfs4id/Makefile.am |   8 ++
>>>>>>>>  tools/nfs4id/nfs4id.c    | 184 
>>>>>>>> +++++++++++++++++++++++++++++++++++++++
>>>>>>>>  tools/nfs4id/nfs4id.man  |  29 ++++++
>>>>>>>>  6 files changed, 227 insertions(+)
>>>>>>>>  create mode 100644 tools/nfs4id/Makefile.am
>>>>>>>>  create mode 100644 tools/nfs4id/nfs4id.c
>>>>>>>>  create mode 100644 tools/nfs4id/nfs4id.man
>>>>>>> Just a nit... naming convention... In the past
>>>>>>> we never put the protocol version in the name.
>>>>>>> Do a ls tools and utils directory and you
>>>>>>> see what I mean....
>>>>>>>
>>>>>>> Would it be a problem to change the name from
>>>>>>> nfs4id to nfsid?
>>>>>> nfs4id is pretty generic, too.
>>>>>> Can we go with nfs-client-id ?
>>>>> I'm never been big with putting '-'
>>>>> in command names... nfscltid would
>>>>> be better IMHO... if we actually
>>>>> need the 'clt' in the name.
>>>>
>>>> We have nfsidmap already. IMO we need some distinction
>>>> with user ID mapping tools... and some day we might
>>>> want to manage server IDs too (see EXCHANGE_ID).
>>> Hmm... So we could not use the same tool to do
>>> both the server and client, via flags?
>>>
>>>>
>>>> nfsclientid then?
>>> You like to type more than I do... You always have... :-)
>>>
>>> But like I started the conversation... the naming is
>>> a nit... but I would like to see one tool to set the
>>> ids for both the server and client... how about
>>> nfsid -s and nfsid -c
>>
>> The tricky thing here is that this little binary isn't going to set
>> anything, and we probably never want people to run it from the 
>> command line.
>>
>> A 'nfsid -s' and 'nfsid -c' seem to want to do much more.  I feel 
>> they are
>> out of scope for the problem I'm trying to solve:  I need something 
>> that
>> will generate a unique value, and persist it, suitable for execution 
>> in a
>> udevd rule.
>>
>> Perhaps we can stop worrying so much about the name of this as I 
>> don't think
>> it should be a first-class nfs-utils command, rather just a helper 
>> for udev.
>>
>> And maybe the name can reflect that - "nfsuuid" ?
>
> The client ID can be an arbitrary string, so I think not.

I feel like we might all be missing the fact that this tool doesn't 
create
client IDs.  The tool only creates uuids, and returns what may have 
already
been set by something somewhere else.  It's not supposed to ever get 
typed
out or run by people.  Any other suggestions?  Here's where we are:

nfs4id - no: we dislike the number 4
nfsuuid - no: it doesn't have to be a uuid
nfsid - no: too ambiguous
nfscltid - no: also too ambiguous
nfsclientid - no: too much typing

Since I've already re-written it, I'm going to send it again as nfsuuid 
-
and let's bikeshed on it again over there, and see if we can make
suggestions that might make everyone happy.

Ben


  reply	other threads:[~2022-02-10 15:47 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-04 12:56 [nfs-utils PATCH] nfs4id: a tool to create and persist nfs4 client uniquifiers Benjamin Coddington
2022-02-04 15:17 ` Chuck Lever III
2022-02-04 15:49   ` Benjamin Coddington
2022-02-04 18:45     ` Chuck Lever III
2022-02-04 19:44       ` Benjamin Coddington
2022-02-05 17:35         ` Chuck Lever III
2022-02-08  3:14       ` NeilBrown
2022-02-08 11:43         ` Benjamin Coddington
2022-02-08 16:04 ` Steve Dickson
2022-02-08 16:21   ` Chuck Lever III
2022-02-08 19:29     ` Steve Dickson
2022-02-08 21:18       ` Chuck Lever III
2022-02-08 22:39         ` Steve Dickson
2022-02-10 13:28           ` Benjamin Coddington
2022-02-10 15:21             ` Chuck Lever III
2022-02-10 15:47               ` Benjamin Coddington [this message]
2022-02-10 16:25                 ` Chuck Lever III
2022-02-10 16:41                   ` Benjamin Coddington
2022-02-10 17:11             ` Steve Dickson
2022-02-08 16:22   ` Benjamin Coddington
2022-02-08 19:52     ` Steve Dickson
2022-02-08 20:00       ` Benjamin Coddington
2022-02-08 22:30         ` Steve Dickson
2022-02-09 13:55           ` Benjamin Coddington
2022-02-09 15:23             ` Steve Dickson
2022-02-09 21:21       ` NeilBrown
2022-02-09 21:45         ` Trond Myklebust
2022-02-09 23:58           ` NeilBrown
2022-02-10 12:25             ` Benjamin Coddington
2022-02-10 22:54               ` NeilBrown
2022-02-11 13:35                 ` Benjamin Coddington
2022-02-13 23:24                   ` NeilBrown
2022-02-14 11:34                     ` Benjamin Coddington

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E0B72831-1575-41CC-BB61-752F9CD0367C@redhat.com \
    --to=bcodding@redhat.com \
    --cc=chuck.lever@oracle.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=steved@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox