you need to rebase ;)

@crosbymichael done :-)

started test on lxc ;) feeling brave

@mrjana Also, you should separate commit message body from title with empty line

very nice at first glance, thanks for vendoring the code in a separated commit, much better for reviewing ⚡

Test failure.

@cpuguy83 thanks. am looking into it.

ping @crosbymichael @jfrazelle @LK4D4 @calavera @cpuguy83

Please note that the code not needed in docker any more like the networkdriver and portmapper haven't been removed yet. It can be removed in subsequent PRs once this one gets merged.

So is that code dead or is it still being called.

I think if it is dead we may as well remove it now, but that is just my opinion, I like large minus (-) ;)

as far as design goes I like it, it is clean and simple.

Yes, don't leave dead code around, it will just be confusing for anyone changing code after you. Don't comment things out either, just delete, everything is in git so we can always see what it was before.

@crosbymichael Sure, let me cleanup dead code.

@jfrazelle I ran lxc integration tests in my dev machine and it had only 7 failures(which was the same on stock 1.7.0-dev in my machine). Does lxc test fail intermittently?

@jfrazelle @crosbymichael @LK4D4
Updated the PR with all the comments taken care

With last commit it is definetely better.

After daemon crash I can't start old container with:

Error response from daemon: Cannot start container c6732738abba: open /var/run/docker/netns/c6732738abba: permission denied
Error: failed to start containers: [c6732738abba]

In logs:

ERRO[0023] leaving endpoint failed: no container attached to the endpoint

Last error probably was here forever, but now it became little more severe. I think we need to call container.cleanup() in daemon.register instead of just container.Unmount

On the good side of things, tests are green with --userland-proxy=false.

@mrjana thanks for the resolv.conf test update--it looks good. Based on that, it appears that any kind of live watching of the host resolver config is now replaced from an implementation perspective by DNS setup step during container start? Given we had no way to do live update of running containers, this seems fully reasonable and at functional parity with today's implementation.

@estesp Yes, that was the only design change which functionally doesn't change anything.

@LK4D4 Thanks for catching the panic issue. Pushed a new set of diffs with the fix for that and a test case for that in libnetwork as well. Also rebased.

/cc @icecrime @crosbymichael

Error response from daemon: Cannot start container c6732738abba: open /var/run/docker/netns/c6732738abba: permission denied
Error: failed to start containers: [c6732738abba]

still here.
And I don't see that you added some code to fix it.
I reproduced like

docker run -d busybox sleep 1000
kill docker with 4 ctrl-C
start docker
docker start old container

also somehow you need rebase again :/ And port #12437

@LK4D4 I pushed new diffs which attempts to fix the issue that you are having. BTW, I was not able to reproduce this issue at all in my local machine. Probably something to do with the version of kernel you are running.

In any case the way I've fixed it is to to remove the namespace path file if it exists during a new join for an old container and recreate the namespace for the container from scratch. Please test it in your machine and see if it works ok.

This is rebased again.

testing now on 4.0.4

On Tue, May 19, 2015 at 5:03 PM, Jana Radhakrishnan <
notifications@github.com> wrote:

@LK4D4 https://github.com/LK4D4 I pushed new diffs which attempts to
fix the issue that you are having. BTW, I was not able to reproduce this
issue at all in my local machine. Probably something to do with the version
of kernel you are running.

In any case the way I've fixed it is to to remove the namespace path file
if it exists during a new join for an old container and recreate the
namespace for the container from scratch. Please test it in your machine
and see if it works ok.

This is rebased again.

—
Reply to this email directly or view it on GitHub
#13060 (comment).

Thanks @jfrazelle

LGTM

Thanks @mrjana @icecrime @LK4D4 @crosbymichael @tiborvass @jfrazelle @estesp @ashahab-altiscale @stevvooe @cpuguy83 @aboch @dave-tucker @nerdalert for a good review & merge.

🎉 🎈 🎆

Finally! 👍

Is there a rough estimate of when this extension may, if approved,make it into the stable branch? 6 months, 12 months, etc.

This perfectly answers some scenarios I have but I need to decide if I implement custom work arounds and leverage third party tools or work on other components of the system until this is in place or those other work arounds need to be done.

Excellent work meanwhile. Simplified elastic-ip like routing between containers is definitely a major hole in the existing feature set.

@noizu This isn't really the right venue to ask this sort of question. I suggest that you use either the mailing list (docker-dev@googlegroups.org) or IRC #docker-dev.