Date:	Fri, 18 Oct 2013 17:34:36 +0200
From:	Nicolas Dichtel <nicolas.dichtel@...nd.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
CC:	Stephen Hemminger <stephen@...workplumber.org>,
	David Miller <davem@...emloft.net>, yamato@...hat.com,
	netdev@...r.kernel.org
Subject: Re: [PATCH] veth: Showing peer of veth type dev in ip link (kernel
 side)

Le 17/10/2013 21:28, Eric W. Biederman a écrit :
> Nicolas Dichtel <nicolas.dichtel@...nd.com> writes:
>
>> Le 16/10/2013 21:53, Eric W. Biederman a écrit :
>
>>> The age old question why can't we have global identifiers for
>>> namespaces?
>>>
>>> The answer is that I don't want to implement a namespace for namespaces.
>> Sorry, but I don't understand the problem. This ID is owned by the kernel, like
>> the netns list (for_each_net()) is owned by it.
>
> The scenario where problem are likely to show up is something like this.
>
> For testing it would be reasonable to setup two linux containers that
> look like full linux systems.  In those containers you run one instance
> of your virtual router managment daemons, and you arrange to synchronize
> between the two linux containers for testing.
>
> It becomes even more interesting when we want to migrate one of those
> linux containers to another physical machine.
>
> Global identifiers start breaking the first scenario, and really trash
> the second scenario.
>
> At the same time migration of configuration and replication of
> configuration are essentially the same problem, so it would be very
> silly to design such that will cause problems.
Ok, I'm now convinced ;-)

>
>>> While the proc inode does work today across different mounts of proc, I
>>> reserve the right at some future date (if it solves a technical problem)
>>> to give each namespace a different inode number in each different mount
>>> of proc.  So the inode number is not quite the unique identifier you
>>> want.  The inode number is a close as I am willing to get to a namespace
>>> of namespaces.
>>>
>>> I think the simplest solution is to just not worry about which namespace
>>> the other half of a veth pair is in.  But I have not encountered the
>>> problem where I need to know exactly which namespace we are worrying
>>> about.
>> Ok, let's start by explaining our usecase.
>>
>> We are using namespaces only to implement virtual routers (VR), ie only
>> the networking stack is virtualized. We don't care about other namespaces, we
>> just want to run several network stacks and beeing able to manage them.
>>
>> For example, providers use this feature to isolate clients, one VR is opened
>> for each client. You can have a large number of clients (+10 000) and thus the
>> same number of netns.
>> Considering these numbers, we don't want to run one instance per VR for all of
>> our network daemons, but have only one instance that manage all VR.
>>
>> You also have daemons that monitor the system and synchronize network objects
>> (interfaces, routes, etc.) on another linux. Goal is to implement an high
>> availablity system: it's possible to switch to the other linux to avoid service
>> interruption.
>> This kind of daemon wants to have the full information about interfaces to be
>> able to build/configure them on the other linux.
>>
>>>
>>> Global identifiers are easy until you hit the cases where they make
>>> things impossible.
>> I don't want specially to use ID, but I fear that the solution with file
>> descriptors will be a nightmare.
>
> I can certainly see challenges.  In asking for symmetry between set and
> get the solution with file descriptors is the obvious answer and the
> first answer I have been able to come up with so far.
>
> My original answer was that the ifindex happened to be unique across
> namespaces but that actually turned out to be a problem for migration
> so that abandoned.
>
> Namespace file descriptors are the solution that I know semantically
> will work.  Beyond that I don't have any good ideas right now.
>
> I just know that local names (aka file descriptors) are much easier to
> work with semantically than global names.
Yes sure. I will continue to think about this.


Thank you,
Nicolas
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists