Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace existing docker networking code and integrate with libnetwork #13060

Merged
merged 3 commits into from May 20, 2015

Conversation

mrjana
Copy link
Contributor

@mrjana mrjana commented May 7, 2015

This PR attempts to integrate libnetwork with three main goals:

  • Modularize docker networking code to a separate package
  • Introduce the first implementation of Container Network Model and make docker purely rely on that
  • Allow more kinds of network drivers to integrated with ease and possibly no change to docker core at all

Please refer to following libnetwork docs for more info:

All dead code has been removed.

@crosbymichael
Copy link
Contributor

you need to rebase ;)

@mrjana
Copy link
Contributor Author

mrjana commented May 7, 2015

@crosbymichael done :-)

@jessfraz
Copy link
Contributor

jessfraz commented May 7, 2015

started test on lxc ;) feeling brave

@LK4D4
Copy link
Contributor

LK4D4 commented May 7, 2015

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

@calavera
Copy link
Contributor

calavera commented May 7, 2015

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

@cpuguy83
Copy link
Member

cpuguy83 commented May 8, 2015

Test failure.

@mavenugo
Copy link
Contributor

mavenugo commented May 8, 2015

@cpuguy83 thanks. am looking into it.

@mrjana mrjana force-pushed the cnm_integ branch 2 times, most recently from 0f5f203 to 72597dd Compare May 10, 2015 19:13
@@ -53,6 +54,10 @@ clone git github.com/kr/pty 05017fcccf
clone git github.com/tchap/go-patricia v2.1.0
clone hg code.google.com/p/go.net 84a4013f96e0
clone hg code.google.com/p/gosqlite 74691fb6f837
clone git github.com/go-fsnotify/fsnotify v1.2.0
clone git github.com/go-check/check 64131543e7896d5bcc6bd5a76287eb75ea96c673
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you pls remove the redundant go-fsnotify and go-check dependencies ?

@mrjana
Copy link
Contributor Author

mrjana commented May 11, 2015

@jessfraz
Copy link
Contributor

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 (-) ;)

@jessfraz
Copy link
Contributor

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

@crosbymichael
Copy link
Contributor

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.

@mrjana
Copy link
Contributor Author

mrjana commented May 11, 2015

@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?

@mrjana
Copy link
Contributor Author

mrjana commented May 12, 2015

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

@LK4D4
Copy link
Contributor

LK4D4 commented May 12, 2015

With last commit it is definetely better.

@LK4D4
Copy link
Contributor

LK4D4 commented May 19, 2015

I found panic:

panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x30 pc=0x75206f]

goroutine 107 [running]:
github.com/docker/libnetwork.(*endpoint).Leave(0xc2082bcf30, 0xc2084753c0, 0x40, 0x0, 0x0, 0x0, 0x0, 0x0)
        /go/src/github.com/docker/docker/vendor/src/github.com/docker/libnetwork/endpoint.go:357 +0x2cf
github.com/docker/docker/daemon.(*Container).ReleaseNetwork(0xc208310000)
        /go/src/github.com/docker/docker/daemon/container.go:961 +0x45f
github.com/docker/docker/daemon.(*Container).cleanup(0xc208310000)
        /go/src/github.com/docker/docker/daemon/container.go:975 +0x36
github.com/docker/docker/daemon.(*containerMonitor).Close(0xc2081557a0, 0x0, 0x0)
        /go/src/github.com/docker/docker/daemon/monitor.go:86 +0x4a
github.com/docker/docker/daemon.func·031()
        /go/src/github.com/docker/docker/daemon/monitor.go:117 +0xbb
github.com/docker/docker/daemon.(*containerMonitor).Start(0xc2081557a0, 0x0, 0x0)
        /go/src/github.com/docker/docker/daemon/monitor.go:180 +0x7af
github.com/docker/docker/daemon.*containerMonitor.Start·fm(0x0, 0x0)
        /go/src/github.com/docker/docker/daemon/container.go:1584 +0x39
github.com/docker/docker/pkg/promise.func·001()
        /go/src/github.com/docker/docker/pkg/promise/promise.go:8 +0x2f
created by github.com/docker/docker/pkg/promise.Go
        /go/src/github.com/docker/docker/pkg/promise/promise.go:9 +0xfb

I created two containers with --net=host and then leave from both. Also you probably want to write test for this situation :)

@LK4D4
Copy link
Contributor

LK4D4 commented May 19, 2015

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

@LK4D4
Copy link
Contributor

LK4D4 commented May 19, 2015

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

@icecrime
Copy link
Contributor

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

@estesp
Copy link
Contributor

estesp commented May 19, 2015

@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.

@mrjana
Copy link
Contributor Author

mrjana commented May 19, 2015

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

@mrjana
Copy link
Contributor Author

mrjana commented May 19, 2015

@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

@LK4D4
Copy link
Contributor

LK4D4 commented May 19, 2015

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

@LK4D4
Copy link
Contributor

LK4D4 commented May 19, 2015

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

Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
    - Updated Dockerfile to satisfy libnetwork GOPATH requirements.
    - Reworked daemon to allocate network resources using libnetwork.
    - Reworked remove link code to also update network resources in libnetwork.
    - Adjusted the exec driver command population to reflect libnetwork design.
    - Adjusted the exec driver create command steps.
    - Updated a few test cases to reflect the change in design.
    - Removed the dns setup code from docker as resolv.conf is entirely managed
      in libnetwork.
    - Integrated with lxc exec driver.

Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
As part of this some generic packages like iptables, etchosts and resolvconf
have also been moved to libnetwork. Even though they can still be
consumed in a generic fashion they will reside and be maintained
from within the libnetwork project.

Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
@mrjana
Copy link
Contributor Author

mrjana commented May 20, 2015

@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.

@jessfraz
Copy link
Contributor

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).

@mrjana
Copy link
Contributor Author

mrjana commented May 20, 2015

Thanks @jfrazelle

@jessfraz
Copy link
Contributor

LGTM

1 similar comment
@icecrime
Copy link
Contributor

LGTM

icecrime pushed a commit that referenced this pull request May 20, 2015
Replace existing docker networking code and integrate with libnetwork
@icecrime icecrime merged commit 496bc46 into moby:master May 20, 2015
@mavenugo
Copy link
Contributor

@fgbreel
Copy link

fgbreel commented May 20, 2015

Finally! 👍

@noizu
Copy link

noizu commented Jul 8, 2015

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.

@stevvooe
Copy link
Contributor

stevvooe commented Jul 8, 2015

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet