Re: [nfs-utils PATCH] nfs4id: a tool to create and persist nfs4 client uniquifiers

["Benjamin Coddington" <bcodding@redhat.com>]

On 10 Feb 2022, at 17:54, NeilBrown wrote:

> On Thu, 10 Feb 2022, Benjamin Coddington wrote:
>>
>> Yes, but even better than having the tool do the writing is to have 
>> udev do
>> it, because udev makes the problem of when and who will execute this 
>> tool go
>> away, and the entire process is configurable for anyone that needs to 
>> change
>> any part of it or use their own methods of generating/storing ids.
>
> I really don't understand the focus on udev.
>
> Something, somewhere, deliberately creates the new network namespace.
> It then deliberately configures that namespace - creating a virtual
> device maybe, adding an IP address, setting a default route or 
> whatever.
> None of that is done by udev rules (is it)?
> Setting the NFS identity is just another part of configuring the new
> network namespace.
>
> udev is great when we don't know exactly when an event will happen, 
> but
> we want to respond when it does.
> That doesn't match the case of creating a new network namespace.  Some
> code deliberately creates it and is perfectly positioned to then
> configure it.

I think there's so many ways to create a new network namespace that we 
can't
reasonably be expected to try to insert out problem into all of them.
Handling the event from the kernel allows us to make a best-effort 
default
attempt.

> udev is async.  How certain can we be that the udev event will be 
> fully
> handled before the first mount attempt?

Good point.  We can't at all be certain.

We can start over completely from here..

We can have mount.nfs /also/ try to configure the id.. this is more 
robust.

We can have mount.nfs do a round of udev settle..

Are there other options?

Ben