All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Dickson <steved@redhat.com>
To: NeilBrown <neilb@suse.de>, Trond Myklebust <trondmy@hammerspace.com>
Cc: "chuck.lever@oracle.com" <chuck.lever@oracle.com>,
	"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
	"bcodding@redhat.com" <bcodding@redhat.com>
Subject: Re: [PATCH] nfs.man: document requirements for NFS mounts in a container
Date: Fri, 4 Mar 2022 10:54:36 -0500	[thread overview]
Message-ID: <3d4467af-e6f7-694b-e711-6fafb6490fc8@redhat.com> (raw)
In-Reply-To: <164635642445.13165.9587906660448735526@noble.neil.brown.name>

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.
> 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.
> 
> 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. :-)

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.

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.


  reply	other threads:[~2022-03-04 15:54 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-10 18:01 [PATCH v2 0/2] nfsuuid and udev examples Benjamin Coddington
2022-02-10 18:01 ` [PATCH v2 1/2] nfsuuid: a tool to create and persist nfs4 client uniquifiers Benjamin Coddington
2022-02-10 18:15   ` Chuck Lever III
2022-02-11 13:44     ` Steve Dickson
2022-02-11 15:48       ` Chuck Lever III
2022-02-11 18:28         ` Benjamin Coddington
2022-02-11 19:04           ` Chuck Lever III
2022-02-11 19:30             ` Benjamin Coddington
2022-02-11 20:00               ` Chuck Lever III
2022-02-11 20:16                 ` Benjamin Coddington
2022-02-11 20:51                   ` Chuck Lever III
2022-02-11 21:06                     ` Benjamin Coddington
2022-02-14  0:04                       ` NeilBrown
2022-02-14 11:15                         ` Benjamin Coddington
2022-02-14 15:39                           ` Chuck Lever III
2022-02-16 19:01                             ` Benjamin Coddington
2022-02-16 19:35                               ` Chuck Lever III
2022-02-16 20:44                                 ` Benjamin Coddington
2022-02-16 23:16                                   ` NeilBrown
2022-03-01  3:43                                     ` [PATCH] nfs.man: document requirements for NFS mounts in a container NeilBrown
2022-03-01 15:08                                       ` Chuck Lever III
2022-03-01 15:16                                         ` Chuck Lever III
2022-03-03  3:26                                         ` NeilBrown
2022-03-03 14:37                                           ` Trond Myklebust
2022-03-04  1:13                                             ` NeilBrown
2022-03-04 15:54                                               ` Steve Dickson [this message]
2022-03-04 16:15                                                 ` Chuck Lever III
2022-03-04 16:54                                                   ` Steve Dickson
2022-03-05  1:15                                                 ` NeilBrown
2022-03-03 15:53                                           ` Chuck Lever III
2022-03-08  0:44                                             ` NeilBrown
2022-03-09 16:28                                               ` Chuck Lever III
2022-03-10  0:37                                                 ` NeilBrown
2022-02-17 14:43                                   ` [PATCH v2 1/2] nfsuuid: a tool to create and persist nfs4 client uniquifiers Chuck Lever III
2022-02-14 22:40                           ` NeilBrown
2022-02-10 18:01 ` [PATCH v2 2/2] nfsuuid: add some example udev rules 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=3d4467af-e6f7-694b-e711-6fafb6490fc8@redhat.com \
    --to=steved@redhat.com \
    --cc=bcodding@redhat.com \
    --cc=chuck.lever@oracle.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=neilb@suse.de \
    --cc=trondmy@hammerspace.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.