@Taku, Please have a look on this discussion. This is all about local and global scope: https://github.com/docker/libnetwork/issues/486
Plus, I used same docker options as you mentioned. Fact that it was working for networks created with overlay driver making me think it was not a configuration issue. Only networks created with kuryr were not getting synced. Thanks Vikas Choudhary On Fri, Nov 6, 2015 at 8:07 AM, Taku Fukushima <tfukush...@midokura.com> wrote: > Hi Vikas, > > I thought the "capability" affected the propagation of the network state > across nodes as well. However, in my environment, where I tried Consul and > ZooKeeper, I observed a new network created in a host is displayed on > another host when I hit "sudo docker network ls" even if I set the > capability to "local", which is the current default. So I'm just wondering > what this capability means. The spec doesn't say much about it. > > > https://github.com/docker/libnetwork/blob/8d03e80f21c2f21a792efbd49509f487da0d89cc/docs/remote.md#set-capability > > I saw your bug report that describes the network state propagation didn't > happen appropriately. I also experienced the issue and I'd say it would be > the configuration issue. Please try with the following option. I'm putting > it in /etc/default/docker and managing the docker daemon through "service" > command. > > DOCKER_OPTS="-D -H unix:///var/run/docker.sock -H :2376 > --cluster-store=consul://192.168.11.14:8500 --cluster-advertise= > 192.168.11.18:2376" > > The network is the only user facing entity in libnetwork for now since the > concept of the "service" is abandoned in the stable Docker 1.9.0 release > and it's shared by libnetwork through libkv across multiple hosts. Endpoint > information is stored as a part of the network information as you > documented in the devref and the network is all what we need so far. > > > https://github.com/openstack/kuryr/blob/d1f4272d6b6339686a7e002f8af93320f5430e43/doc/source/devref/libnetwork_remote_driver_design.rst#libnetwork-user-workflow-with-kuryr-as-remote-network-driver---host-networking > > Regarding changing the capability to "global", it totally makes sense and > we should change it despite the networks would be shared among multiple > hosts anyways. > > Best regards, > Taku Fukushima > > > On Thu, Nov 5, 2015 at 8:39 PM, Vikas Choudhary < > choudharyvika...@gmail.com> wrote: > >> Thanks Toni. >> On 5 Nov 2015 16:02, "Antoni Segura Puimedon" < >> toni+openstac...@midokura.com> wrote: >> >>> >>> >>> On Thu, Nov 5, 2015 at 10:47 AM, Vikas Choudhary < >>> choudharyvika...@gmail.com> wrote: >>> >>>> ++ [Neutron] tag >>>> >>>> >>>> On Thu, Nov 5, 2015 at 10:40 AM, Vikas Choudhary < >>>> choudharyvika...@gmail.com> wrote: >>>> >>>>> Hi all, >>>>> >>>>> By network control plane i specifically mean here sharing network >>>>> state across docker daemons sitting on different hosts/nova_vms in >>>>> multi-host networking. >>>>> >>>>> libnetwork provides flexibility where vendors have a choice between >>>>> network control plane to be handled by libnetwork(libkv) or remote driver >>>>> itself OOB. Vendor can choose to "mute" libnetwork/libkv by advertising >>>>> remote driver capability as "local". >>>>> >>>>> "local" is our current default "capability" configuration in kuryr. >>>>> >>>>> I have following queries: >>>>> 1. Does it mean Kuryr is taking responsibility of sharing network >>>>> state across docker daemons? If yes, network created on one docker host >>>>> should be visible in "docker network ls" on other hosts. To achieve this, >>>>> I >>>>> guess kuryr driver will need help of some distributed data-store like >>>>> consul etc. so that kuryr driver on other hosts could create network in >>>>> docker on other hosts. Is this correct? >>>>> >>>>> 2. Why we cannot set default scope as "Global" and let libkv do the >>>>> network state sync work? >>>>> >>>>> Thoughts? >>>>> >>>> >>> Hi Vikas, >>> >>> Thanks for raising this. As part of the current work on enabling >>> multi-node we should be moving the default to 'global'. >>> >>> >>>> >>>>> Regards >>>>> -Vikas Choudhary >>>>> >>>> >>>> >>>> >>>> __________________________________________________________________________ >>>> OpenStack Development Mailing List (not for usage questions) >>>> Unsubscribe: >>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev