Message-ID: <ba0f624c-fc24-a3f4-749a-00e419960de2@gmail.com>
Date:   Mon, 22 Nov 2021 15:02:56 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.2.1
Subject: Re: [RFC PATCH 0/4] namespacefs: Proof-of-Concept
Content-Language: en-US
To:     James Bottomley <James.Bottomley@HansenPartnership.com>,
        Steven Rostedt <rostedt@goodmis.org>
Cc:     linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
        viro@zeniv.linux.org.uk, mingo@redhat.com, hagen@jauu.net,
        rppt@kernel.org, akpm@linux-foundation.org, vvs@virtuozzo.com,
        shakeelb@google.com, christian.brauner@ubuntu.com,
        mkoutny@suse.com, Linux Containers <containers@lists.linux.dev>,
        "Eric W. Biederman" <ebiederm@xmission.com>
References: <20211118181210.281359-1-y.karadz@gmail.com>
 <87a6i1xpis.fsf@email.froward.int.ebiederm.org>
 <20211118142440.31da20b3@gandalf.local.home>
 <1349346e1d5daca991724603d1495ec311cac058.camel@HansenPartnership.com>
 <20211119092758.1012073e@gandalf.local.home>
 <f6ca1f5bdb3b516688f291d9685a6a59f49f1393.camel@HansenPartnership.com>
 <20211119114736.5d9dcf6c@gandalf.local.home>
 <20211119114910.177c80d6@gandalf.local.home>
 <cc6783315193be5acb0e2e478e2827d1ad76ba2a.camel@HansenPartnership.com>
From:   Yordan Karadzhov <y.karadz@gmail.com>
In-Reply-To: <cc6783315193be5acb0e2e478e2827d1ad76ba2a.camel@HansenPartnership.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk


On 20.11.21 г. 1:08 ч., James Bottomley wrote:
> [trying to reconstruct cc list, since the cc: field is bust again]
>> On Fri, 19 Nov 2021 11:47:36 -0500
>> Steven Rostedt <rostedt@goodmis.org> wrote:
>>
>>>> Can we back up and ask what problem you're trying to solve before
>>>> we start introducing new objects like namespace name?
>>
>> TL;DR; verison:
>>
>> We want to be able to install a container on a machine that will let
>> us view all namespaces currently defined on that machine and which
>> tasks are associated with them.
>>
>> That's basically it.
> 
> So you mentioned kubernetes.  Have you tried
> 
> kubectl get pods --all-namespaces
> 
> ?
> 
> The point is that orchestration systems usually have interfaces to get
> this information, even if the kernel doesn't.  In fact, userspace is
> almost certainly the best place to construct this from.
> 
> To look at this another way, what if you were simply proposing the
> exact same thing but for the process tree.  The push back would be that
> we can get that all in userspace and there's even a nice tool (pstree)
> to do it which simply walks the /proc interface.  Why, then, do we have
> to do nstree in the kernel when we can get all the information in
> exactly the same way (walking the process tree)?
> 


I see on important difference between the problem we have and the problem in your example. /proc contains all the 
information needed to unambiguously reconstruct the process tree.

On the other hand, I do not see how one can reconstruct the namespace tree using only the information in proc/ (maybe 
this is because of my ignorance).

Let's look the following case (oversimplified just to get the idea):
1. The process X is a parent of the process Y and both are in namespace 'A'.
3. "unshare" is used to place process Y (and all its child processes) in a new namespace B (A is a parent namespace of B).
4. "setns" is s used to move process X in namespace C.

How would you find the parent namespace of B?

Again, using your arguments, I can reformulate the problem statement this way: a userspace program is well instrumented 
to create an arbitrary complex tree of namespaces. In the same time, the only place where the information about the 
created structure can be retrieved is in the userspace program itself. And when we have multiple userspace programs 
adding to the namespaces tree, the global picture gets impossible to recover.

Thanks!
Yordan


> James
> 
> 
>