Re: [RFC PATCH 0/4] namespacefs: Proof-of-Concept

From: Kirill Tkhai <ktkhai@virtuozzo.com>
To: Steven Rostedt <rostedt@goodmis.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>
Cc: "Yordan Karadzhov (VMware)" <y.karadz@gmail.com>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	viro@zeniv.linux.org.uk, mingo@redhat.com, hagen@jauu.net,
	rppt@kernel.org, James.Bottomley@HansenPartnership.com,
	akpm@linux-foundation.org, vvs@virtuozzo.com,
	shakeelb@google.com, christian.brauner@ubuntu.com,
	mkoutny@suse.com, Linux Containers <containers@lists.linux.dev>
Subject: Re: [RFC PATCH 0/4] namespacefs: Proof-of-Concept
Date: Fri, 19 Nov 2021 12:50:20 +0300	[thread overview]
Message-ID: <40a50479-c18d-7f2a-bcb2-7c8eb5376381@virtuozzo.com> (raw)
In-Reply-To: <20211118142440.31da20b3@gandalf.local.home>

On 18.11.2021 22:24, Steven Rostedt wrote:
> On Thu, 18 Nov 2021 12:55:07 -0600
> ebiederm@xmission.com (Eric W. Biederman) wrote:
> 
>> It is not correct to use inode numbers as the actual names for
>> namespaces.
>>
>> I can not see anything else you can possibly uses as names for
>> namespaces.
> 
> This is why we used inode numbers.

The migration problem may be solved in case of the new filesystem
allows rename.

Kernel may use random UUID as initial namespace file. After the migration, 
we recreate this namespace, and it will have another UUID generated by kernel.
Then, we just rename it in correct one. 

I sent something like this for /proc fs (except rename): 

http://archive.lwn.net:8080/linux-fsdevel/97fdcff1-1cce-7eab-6449-7fe10451162d@virtuozzo.com/T/#m7579f79a6ba8422b57463049f52d2043986b5cac

>>
>> To allow container migration between machines and similar things
>> the you wind up needing a namespace for your names of namespaces.
> 
> Is this why you say inode numbers are incorrect?
> 
> There's no reason to make this into its own namespace. Ideally, this file
> system should only be for privilege containers. As the entire point of this
> file system is to monitor the other containers on the system. In other
> words, this file system is not to be used like procfs, but instead a global
> information of the containers running on the host.
> 
> At first, we were not going to let this file system be part of any
> namespace but the host itself, but because we want to wrap up tooling into
> a container that we can install on other machines as a way to monitor the
> containers on each machine, we had to open that up.
> 
>>
>> Further you talk about hierarchy and you have not added support for the
>> user namespace.  Without the user namespace there is not hierarchy with
>> any namespace but the pid namespace. There is definitely no meaningful
>> hierarchy without the user namespace.
> 
> Great, help us implement this.
> 
>>
>> As far as I can tell merging this will break CRIU and container
>> migration in general (as the namespace of namespaces problem is not
>> solved).
> 
> This is not to be a file system that is to be migrated. As the point of
> this file system is to monitor the other containers, so it does not make
> sense to migrate it.
> 
>>
>> Since you are not solving the problem of a namespace for namespaces,
>> yet implementing something that requires it.
> 
> Why is it needed?
> 
>>
>> Since you are implementing hierarchy and ignoring the user namespace
>> which gives structure and hierarchy to the namespaces.
> 
> We are not ignoring it, we are RFC'ing for advice on how to implement it.
> 
>>
>> Since this breaks existing use cases without giving a solution.
> 
> You don't understand proof-of-concepts and RFCs do you?
> 
> -- Steve
> 