Re: C/R minisummit notes (namespace naming)

[ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)]

Daniel Lezcano <dlezcano-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org> writes:

>>> Eric will post a patch to automatically destroy the virtual devices when the
>>> netns is destroyed, so there is no way to know if a network  namespace is
>>> dead or not as the uevent socket will not deliver an event  outside of the
>>> container.
>>
>> My question remains: who cares?
>
> The container implementation in userspace. Let's imagine it sets some routes
> outside of the container to route the traffic to the container. It should remove
> these routes when the container dies. And the container should be considered as
> dead when the network has died and not when the last process of the container
> exits.

Namespaces can definitely live on long past the time when there are any tasks
that point to them from nsproxy, and knowing when that happens would be nice.
So settling on pids for names would be nice as that would allows us to restructure
/proc so that we could see those kinds of things.

That said I am less certain of the need to actually wait for a network namespace
to exit, once we start killing virtual network devices.

It was mentioned that ip over ip tunnels don't currently have a dellink method so we need
will still need a wait to handle that case.

Similarly in general we need to wait until the network namespace exits to ensure
we flush all of the outgoing packets at container shutdown.

So I propose we remove merge the code to wait on delete virtual devices and then
recheck to see what uses we actually have left.

Eric