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. Thanks, NeilBrown
