<div dir="ltr">Hi Vikas,<div><br></div><div>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.</div><div><br></div><div><a href="https://github.com/docker/libnetwork/blob/8d03e80f21c2f21a792efbd49509f487da0d89cc/docs/remote.md#set-capability">https://github.com/docker/libnetwork/blob/8d03e80f21c2f21a792efbd49509f487da0d89cc/docs/remote.md#set-capability</a><br></div><div><br></div><div>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.</div><div><br></div><div>DOCKER_OPTS="-D -H unix:///var/run/docker.sock -H :2376 --cluster-store=consul://<a href="http://192.168.11.14:8500">192.168.11.14:8500</a> --cluster-advertise=<a href="http://192.168.11.18:2376">192.168.11.18:2376</a>"<br></div><div><br></div><div>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.</div><div><br></div><div><a href="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">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</a><br></div><div><br></div><div>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.<br><div><br></div><div>Best regards,</div><div>Taku Fukushima</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 5, 2015 at 8:39 PM, Vikas Choudhary <span dir="ltr"><<a href="mailto:choudharyvikas16@gmail.com" target="_blank">choudharyvikas16@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Thanks Toni.</p><div class="HOEnZb"><div class="h5">
<div class="gmail_quote">On 5 Nov 2015 16:02, "Antoni Segura Puimedon" <<a href="mailto:toni%2Bopenstackml@midokura.com" target="_blank">toni+openstackml@midokura.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 5, 2015 at 10:47 AM, Vikas Choudhary <span dir="ltr"><<a href="mailto:choudharyvikas16@gmail.com" target="_blank">choudharyvikas16@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">++ [Neutron] tag<div><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 5, 2015 at 10:40 AM, Vikas Choudhary <span dir="ltr"><<a href="mailto:choudharyvikas16@gmail.com" target="_blank">choudharyvikas16@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi all,<div><br></div><div>By network control plane i specifically mean here sharing network state across docker daemons sitting on different hosts/nova_vms in multi-host networking.<br></div><div><br></div><div>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".</div><div><br></div><div>"local" is our current default "capability" configuration in kuryr.</div><div><br></div><div>I have following queries:</div><div>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?</div><div><br></div><div>2. Why we cannot  set default scope as "Global" and let libkv do the network state sync work?</div><div><br></div><div>Thoughts?</div></div></blockquote></div></div></div></div></div></blockquote><div><br></div><div>Hi Vikas,<br><br></div><div>Thanks for raising this. As part of the current work on enabling multi-node we should be moving the default to 'global'.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Regards</div><span><font color="#888888"><div>-Vikas Choudhary</div></font></span></div>
</blockquote></div><br></div></div></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>