From: Nicolas Dichtel <nicolas.dichtel@6wind•com>
To: "Eric W. Biederman" <ebiederm@xmission•com>
Cc: Stephen Hemminger <stephen@networkplumber•org>,
David Miller <davem@davemloft•net>,
yamato@redhat•com, netdev@vger•kernel.org
Subject: Re: [PATCH] veth: Showing peer of veth type dev in ip link (kernel side)
Date: Fri, 18 Oct 2013 17:34:36 +0200 [thread overview]
Message-ID: <5261550C.6010403@6wind.com> (raw)
In-Reply-To: <8738nzelxl.fsf@xmission.com>
Le 17/10/2013 21:28, Eric W. Biederman a écrit :
> Nicolas Dichtel <nicolas.dichtel@6wind•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
next prev parent reply other threads:[~2013-10-18 15:34 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-04 2:34 [PATCH] veth: Showing peer of veth type dev in ip link (kernel side) Masatake YAMATO
2013-10-08 19:23 ` David Miller
2013-10-08 21:13 ` Stephen Hemminger
2013-10-09 1:52 ` David Miller
[not found] ` <20131009165254.2e1c8332@nehalam.linuxnetplumber.net>
2013-10-10 0:17 ` Eric W. Biederman
2013-10-15 16:44 ` Nicolas Dichtel
2013-10-15 20:34 ` Eric W. Biederman
2013-10-16 10:08 ` Nicolas Dichtel
2013-10-16 19:53 ` Eric W. Biederman
2013-10-17 16:05 ` Nicolas Dichtel
2013-10-17 19:28 ` Eric W. Biederman
2013-10-18 15:34 ` Nicolas Dichtel [this message]
-- strict thread matches above, loose matches on Subject: below --
2013-10-04 4:05 Masatake YAMATO
2013-10-04 4:49 ` Eric Dumazet
2013-10-04 15:21 ` Nicolas Dichtel
2013-10-04 17:55 ` Stephen Hemminger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5261550C.6010403@6wind.com \
--to=nicolas.dichtel@6wind$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=ebiederm@xmission$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=stephen@networkplumber$(echo .)org \
--cc=yamato@redhat$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox