> On Feb 4, 2022, at 2:44 PM, Benjamin Coddington <bcodding@xxxxxxxxxx> wrote: > > On 4 Feb 2022, at 13:45, Chuck Lever III wrote: > >>> On Feb 4, 2022, at 10:49 AM, Benjamin Coddington <bcodding@xxxxxxxxxx> wrote: >>> >>> On 4 Feb 2022, at 10:17, Chuck Lever III wrote: >>> >>>> As discussed in earlier threads, we believe that storing multiple unique-ids >>>> in one file, especially without locking to prevent tearing of data in the >>>> file, is problematic. Now, it might be that the objection to this was based >>>> on storing these in a file that can simultaneously be edited by humans >>>> (ie, /etc/nfs.conf). But I would prefer to see a separate file used for >>>> each uniquifier / network namespace. >>> >>> This tool isn't trying to store uniquifiers for multiple namespaces, or >>> describe how it ought to be used in relation to namespaces. It only >>> attempts to create a fairly persistent unique value that can be generated >>> and consumed from a udev rule. >>> >>> I think the problem of how to create uniquifiers for every net namespace >>> might easily be solved by bind-mounding /etc/nfs4-id into the >>> namespace-specific filesystem, or a number of other ways. That would be an >>> interesting new topic. >> >> I don't think that's a new topic at all. This mechanism needs to >> deal with containers properly from day one. That's why we are >> using a udev rule for this purpose in the first place instead of >> something more obvious. > > This isn't a mechanism to deal with containers, its a small helper utility > that we'd like to use to solve an existing, non-container problem in a way > that's future-proof for containers. I understand that it doesn't support containers. I also understand that the uniquifier issue is a nagging and ongoing problem that needs to be rectified as soon as possible. I'm not pushing back on this without (good) reason, and I will try to be as helpful as I can to move this forward. I don't believe the solution to this problem is complete unless it deals with containers. I fear that the simpler non-container solution will be merged and then we will all put our pencils down and never deal properly with NFSv4 in containers. Or, that we will get farther down the road and discover that the simple solution has painted us into a corner, and significant visible changes will be necessary to get proper container support. (This viewpoint is based on watching other subsystems attempt to go from single instance to container support). I'd like to have some confidence that neither of those things will happen, and I don't think it will take a lot more effort to see that this is a proper and complete solution. To be absolutely clear, I want to see this issue resolved, but without adding more long-term to-dos or other issues hanging over our heads. >> The problem is that a network namespace (to which the persistent >> uniquifier is attached) and an FS namespace (in which the persistent >> uniquifier is stored) are created and managed independently. >> >> We need to agree on how NFSv4 clients in containers are to be >> supported before the proposed tool can be evaluated fully. > > I disagree. This tool is immediately useful when I have multiple NAT-ed NFS > clients with the same hostnames and they end up with identical NFS client > identifiers. That's the problem this little utility helps to solve, and > that's the real-world issue we've been asked to fix. The real-world problem is linked to the container issue whether Red Hat likes it or not. Upstream we have to think about the larger issues. Again, I do understand the narrower scope of your bugzilla / enhancement request. Yes, your proposal addresses the narrowly defined issue, but I'm concerned that it will introduce long- term problems. > I don't think we have to solve all the problems at once, and I think this is > headed in the right direction. This is the best solution I've seen so far, but it needs a little more design thinking IMHO. Like earlier proposals, there is still a possibility that significant and visible changes will be necessary to convert from single instance systems to containers. I'd really really like to avoid that, and I believe our users would also appreciate it. > I can commit to working on the namespace part.. I very much appreciate your effort. > but there's a number of things that aren't clear to me there: > > - is udev namespace-aware? I thought that it was. That was supposed to be the reason Trond went with a udev rule mechanism. The rule is supposed to fire when each network namespace is created. > - can we get udev rules to trigger for a namespace (my simple tests show > that my "root" system-udevd doesnt see the creation or entry of processes > into a new network namespace) Maybe we need to run udevd in every > network namespace? > > - can uniquifiers be network-namespace uniquified by just using information > available within a udev rule, or do we really need this utility to be > namespace aware? I thought that was how this mechanism was supposed to work. I believe Trond even posted an example rule at some point in the past. > There's a bunch of stuff to discuss and figure out (unless someone else > already has), maybe we can start a new thread? Since neither of us is 100% certain, can you find a container or udev expert inside of Red Hat who can give some guidance? -- Chuck Lever
