Open Stack

@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 <tfukushima at 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 <
> choudharyvikas16 at gmail.com> wrote:
>
>> Thanks Toni.
>> On 5 Nov 2015 16:02, "Antoni Segura Puimedon" <
>> toni+openstackml at midokura.com> wrote:
>>
>>>
>>>
>>> On Thu, Nov 5, 2015 at 10:47 AM, Vikas Choudhary <
>>> choudharyvikas16 at gmail.com> wrote:
>>>
>>>> ++ [Neutron] tag
>>>>
>>>>
>>>> On Thu, Nov 5, 2015 at 10:40 AM, Vikas Choudhary <
>>>> choudharyvikas16 at 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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151106/8156f022/attachment.html>