Skip to content
This repository has been archived by the owner on Jun 20, 2024. It is now read-only.

Make Plugin work with Docker Swarmkit #2651

Closed
brb opened this issue Nov 17, 2016 · 10 comments
Closed

Make Plugin work with Docker Swarmkit #2651

brb opened this issue Nov 17, 2016 · 10 comments

Comments

@brb
Copy link
Contributor

brb commented Nov 17, 2016

Relevant info (taken from emails "weave in docker swarm mode"):

  • "Both the Swarmkit and Libnetwork PRs are merged and global-scoped network v1-plugins should work just fine. Since swarm-mode brings in the concept of manager/workers and the global network resources are allocated and managed by the manager, we have introduced 2 additional driver APIs (NetworkAllocate and NetworkFree) which will be invoked in the manager resource allocation pipeline. Pls refer to ovmanager.go for a reference global-scoped driver implementation. Also, pls refer to the IT in my docker PR (Allow multiple handlers to support network plugins in swarm-mode  moby/moby#27287)."
  • "CreateNetwork and NetworkAllocate are 2 completely different APIs with different meanings. NetworkAllocate is called only on the swarm manager and is corresponding to the global resource allocation. Plugins can choose to add any metadata here (which will be delivered during CreateNetwork on the workers). Please refer to ovmanager.go for more information. CreateNetwork stays exactly the same and it will be called when a container is launched on worker nodes just as it is today. The network-id will be the same as seen in NetworkAllocate and will also carry the metadata passed by the driver in NetworkAllocate."

There are two PoC's:

In order to be a backward compatible with older versions of Docker, we should keep CreateNetwork as it is.

Please note, that Plugin is expected to work only in the global scope.

@brb brb added this to the 1.9.0 milestone Nov 17, 2016
@brb
Copy link
Contributor Author

brb commented Nov 17, 2016

/cc @lukemarsden

@bboreham
Copy link
Contributor

Please note, that Plugin is expected to work only in the global scope

I think you mean the weave plugin; the weavemesh plugin is local scope.

It's acceptable that weavemesh be incompatible with Swarm and/or Swarm Mode

@brb
Copy link
Contributor Author

brb commented Nov 17, 2016

I think you mean the weave plugin; the weavemesh plugin is local scope.

Yep, I meant the weave plugin.

@rade
Copy link
Member

rade commented Nov 17, 2016

I think this is a dup of #2396.

@bboreham
Copy link
Contributor

bboreham commented Jan 4, 2017

I am having trouble working out what is and isn't supposed to work.

In my tests, the 'local scope' plugin from unmodified Weave works with Docker 1.12.5 and 1.13-rc4: I can docker run -ti --net=weave bash on two Swarm-mode machines and ping between them.

With Docker 1.12.5 joined to the swarm I can create a global-scope network but not use it:

$ docker network create --driver=weave foo2
qhwfyjy65r26wy9d7kik6ydio
$ docker run -tdi --net=foo2 bash
docker: Error response from daemon: network foo2 not found.

With Docker 1.13-rc4 I get a different error:

$ docker run -tdi --net=foo2 bash
72b973f3a2308413e33f37efca3d0b551b6e8d6240f0df5becfc1c3afada8e3e
docker: Error response from daemon: Could not attach to network foo2: rpc error: code = 7 desc = network foo2 not manually attachable.

If I try to address that I get yet another error:

$ docker network create --driver=weave --attachable=true foo3
0hxlnx44cfhtv2k3wqsgl2yph
$ docker run -tdi --net=foo3 bash
3427468973c58141f9479a5747957238678ba49581376803fbaa5c1e59dee47f
docker: Error response from daemon: attaching to network failed, make sure your network options are correct and check manager logs: context deadline exceeded.

This error happens the same with both candidate versions of the change, and with weave built from master.

@bboreham
Copy link
Contributor

bboreham commented Jan 5, 2017

Based on further info from @lukemarsden I see this fail with Docker 1.12.5:

$ docker network create --driver=weave foo
Error response from daemon: rpc error: code = 3 desc = invalid driver specified

(this is different from what I saw earlier; perhaps some data was incorrect)

With Docker 1.13-rc4 the network create succeeds, but an attempt to use it to create a service fails:

$ docker service create --mode=global --network=foo --name cam7 nginx
us2u0x3bztkidab6r2mi8d28d
$ docker service ls
ID            NAME  MODE    REPLICAS  IMAGE
us2u0x3bztki  cam7  global  0/1       nginx:latest

Note the number of REPLICAS is 0.

Running Docker in debug mode shows this after service create; does not seem to help:

Jan 05 13:15:53 host1 docker[15571]: time="2017-01-05T13:15:53.000000579Z" level=debug msg="Calling POST /v1.25/services/create"
Jan 05 13:15:53 host1 docker[15571]: time="2017-01-05T13:15:53.000297215Z" level=debug msg="form data: {\"EndpointSpec\":{},\"Mode\":{\"Global\":{}},\"Name\":\"myservice\",\"Networks\":[{\"Target\":\"foo\"}],\"TaskTemplate\":{\"ContainerSpec\":{\"DNSConfig\":{},\"Image\":\"nginx\"},\"ForceUpdate\":0,\"Networks\":[{\"Target\":\"foo\"}],\"Placement\":{},\"Resources\":{\"Limits\":{},\"Reservations\":{}},\"RestartPolicy\":{}},\"UpdateConfig\":{\"FailureAction\":\"pause\",\"MaxFailureRatio\":0,\"Parallelism\":1}}"
Jan 05 13:15:55 host1 docker[15571]: time="2017-01-05T13:15:55.414614358Z" level=debug msg="pinning image nginx by digest: nginx:latest@sha256:fab482910aae9630c93bd24fc6fcecb9f9f792c24a8974f5e46d8ad625ac2357"
Jan 05 13:15:55 host1 docker[15571]: time="2017-01-05T13:15:55.418207923Z" level=debug msg="RequestAddress(GlobalDefault/10.0.0.0/24, <nil>, map[])"
Jan 05 13:15:55 host1 docker[15571]: time="2017-01-05T13:15:55.420515112Z" level=debug msg="RequestAddress(GlobalDefault/10.0.0.0/24, <nil>, map[])"

@bboreham
Copy link
Contributor

bboreham commented Jan 5, 2017

Trying with a build of 1.13-rc5 it works.

@bboreham
Copy link
Contributor

bboreham commented Jan 9, 2017

My mistake; it worked because I had made a change to the filtering logic. Latest status is swarm mode does not support "v1" plugins.

@bboreham bboreham modified the milestones: 1.9.0, 1.10 Jan 10, 2017
@brb brb assigned marccarre and unassigned bboreham Feb 7, 2017
@pidster
Copy link
Contributor

pidster commented Feb 15, 2017

See also: #2805

@brb brb self-assigned this Feb 28, 2017
@marccarre
Copy link
Contributor

Fixed by #2727.

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

No branches or pull requests

5 participants