> On Feb 11, 2022, at 1:28 PM, Benjamin Coddington <bcodding@xxxxxxxxxx> wrote: > > On 11 Feb 2022, at 10:48, Chuck Lever III wrote: > >>> On Feb 11, 2022, at 8:44 AM, Steve Dickson <SteveD@xxxxxxxxxx> wrote: >>> >>> On 2/10/22 1:15 PM, Chuck Lever III wrote: >>>>> On Feb 10, 2022, at 1:01 PM, Benjamin Coddington <bcodding@xxxxxxxxxx> 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. Yes. We're not using the output of the tool for anything else. At the very least the man page should explain the proposed client ID usage as an EXAMPLE with an explanation. But honestly, I haven't seen any use case that requires this exact functionality. Can you explain why you believe there needs to be extra generality? (that's been one of the main reasons I object to "nfsuuid" -- what else can this tool be used for?) > 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? It could do that, but the part that the kernel struggles with is the uniquifier part. That is the part that _has_ to be done in user space (because that's the part that requires persistence). The rest of the nfs_client_id4 argument can be formed in the kernel. > Right now nfsuuid outputs uuids (or whatever was previously stored, up to 64 > chars). Right. It can output anything, not just a UUID. It will output whatever is in the special file. If the content of that file is a random string, what will nfsuuid output? If someone runs nfsuuid expecting a UUID and gets the random crap that was previously stored in the persistence file, wouldn't that be surprising? Precisely because it has the ability to output whatever is in the persistence file, and that file does not have to contain a UUID, that makes this tool not "nfsuuid". > 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? No: a UUID is a data type. Would you call the tool nfsunsignedint if we stored the ino of the net namespace instead? Do you have any other specific use cases for an nfsuuid tool today? If you do, then you have a platform for more generality. If not, then there really isn't any other purpose for this tool. It is a single-tasker, and we shouldn't treat it otherwise. -- Chuck Lever
