Re: [PATCH] nfs.man: document requirements for NFS mounts in a container

[Steve Dickson <steved@redhat.com>]

On 3/4/22 11:15 AM, Chuck Lever III wrote:
> 
> 
>> On Mar 4, 2022, at 10:54 AM, Steve Dickson <steved@redhat.com> wrote:
>>
>> Hey!
>>
>> On 3/3/22 8:13 PM, NeilBrown wrote:
>>> On Fri, 04 Mar 2022, Trond Myklebust wrote:
>>>> On Thu, 2022-03-03 at 14:26 +1100, NeilBrown wrote:
>>>>> On Wed, 02 Mar 2022, Chuck Lever III wrote:
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> The remaining part of this text probably should be
>>>>>> part of the man page for Ben's tool, or whatever is
>>>>>> coming next.
>>>>>
>>>>> My position is that there is no need for any tool.  The total amount
>>>>> of
>>>>> code needed is a couple of lines as presented in the text below.  Why
>>>>> provide a wrapper just for that?
>>>>> We *cannot* automatically decide how to find a name or where to store
>>>>> a
>>>>> generated uuid, so there is no added value that a tool could provide.
>>>>>
>>>>> We cannot unilaterally fix container systems.  We can only tell
>>>>> people
>>>>> who build these systems of the requirements for NFS.
>>>>>
>>>>
>>>> I disagree with this position. The value of having a standard tool is
>>>> that it also creates a standard for how and where the uniquifier is
>>>> generated and persisted.
>>>>
>>>> Otherwise you have to deal with the fact that you may have a systemd
>>>> script that persists something in one file, a Dockerfile recipe that
>>>> generates something at container build time, and then a home-made
>>>> script that looks for something in a different location. If you're
>>>> trying to debug why your containers are all generating the same
>>>> uniquifier, then that can be a problem.
>>> I don't see how a tool can provide any consistency.
> 
> It seems to me that having a tool with its own man page directed
> towards Linux distributors would be the central place for this
> kind of configuration and implementation. Otherwise, we will have
> to ensure this is done correctly for each implementation of
> mount.
> 
> 
>>> Is there some standard that say how containers should be built, and
>>> where tools can store persistent data?  If not, the tool needs to be
>>> configured, and that is not importantly different from bash being
>>> configured with a 1-line script to write out the identifier.
> 
> IMO six of one, half dozen of another. I don't see this being
> any more or less safe than changing each implementation of mount
> to deal with an NFS-specific setting.
> 
> 
>>> I'm not strongly against a tools, I just can't see the benefit.
>> I think I agree with this... Thinking about it... having a command that
>> tries to manipulate different containers in different ways just
>> seems like a recipe for disaster... I just don't see how a command would
>> ever get it right... Hell we can't agree on its command's name
>> much less what it will do. :-)
> 
> To be clear what you are advocating, each implementation of mount.nfs,
> including the ones that are not shipped with nfs-utils (like Busybox
> and initramfs) will need to provide a mechanism for setting the client
> uniquifier. Just to confirm that is what is behind door number one.
Well I can't speak for mount.nfs that are not in nfs-utils.
I'm assuming they are going to do... what are going to do...
regardless of what we do. At least we will give them a
guideline of what needs to be done.


> 
> Since it is just a line or two of code, it might be of little
> harm just to go with separate implementations for now and stop
> talking about it. If it sucks, we can fix the suckage.
Right I see documenting what needs to happen is the
first step. Heck don't we even know how accurate that
documentation is... yet! Once we vet the doc to make
sure it is accurate... Maybe then we could come up
with a auto-configuration solution that has been
proposed.

> 
> Who volunteers to implement this mechanism in mount.nfs ?Well, there has been 3 implementations shot down
which tells me, as a community, we need to get
more of an idea of what needs to happen and how.
That's why I think Neil's man page additions
is a good start.

> 
> 
>> So I like idea of documenting when needs to happen in the
>> different types of containers... So I think the man page
>> is the way to go... and I think it is the safest way to go.
>>
>> Chuck, if you would like tweak the verbiage... by all means.
> 
> I stand ready.
That I have confidence in. :-) Thank you!

steved.
> 
> 
>> Neil, will be a V2 for man page patch from this discussion
>> or should I just take the one you posted? If you do post
>> a V2, please start a new thread.
>>
>> steved.
> 
> --
> Chuck Lever
> 
> 
>