[openstack-dev] [magnum] containers across availability zones
Adrian Otto
adrian.otto at rackspace.com
Wed Feb 24 21:03:39 UTC 2016
Ricardo,
The blueprint is approved, thanks!
Adrian
> On Feb 24, 2016, at 2:53 PM, Ricardo Rocha <rocha.porto at gmail.com> wrote:
>
> Thanks, done.
>
> https://blueprints.launchpad.net/magnum/+spec/magnum-availability-zones
>
> We might have something already to expose the labels in the docker
> daemon config.
>
> On Wed, Feb 24, 2016 at 6:01 PM, Vilobh Meshram
> <vilobhmeshram.openstack at gmail.com> wrote:
>> +1 from me too for the idea. Please file a blueprint. Seems feasible and
>> useful.
>>
>> -Vilobh
>>
>>
>> On Tue, Feb 23, 2016 at 7:25 PM, Adrian Otto <adrian.otto at rackspace.com>
>> wrote:
>>>
>>> Ricardo,
>>>
>>> Yes, that approach would work. I don’t see any harm in automatically
>>> adding tags to the docker daemon on the bay nodes as part of the swarm heat
>>> template. That would allow the filter selection you described.
>>>
>>> Adrian
>>>
>>>> On Feb 23, 2016, at 4:11 PM, Ricardo Rocha <rocha.porto at gmail.com>
>>>> wrote:
>>>>
>>>> Hi.
>>>>
>>>> Has anyone looked into having magnum bay nodes deployed in different
>>>> availability zones? The goal would be to have multiple instances of a
>>>> container running on nodes across multiple AZs.
>>>>
>>>> Looking at docker swarm this could be achieved using (for example)
>>>> affinity filters based on labels. Something like:
>>>>
>>>> docker run -it -d -p 80:80 --label nova.availability-zone=my-zone-a
>>>> nginx
>>>> https://docs.docker.com/swarm/scheduler/filter/#use-an-affinity-filter
>>>>
>>>> We can do this if we change the templates/config scripts to add to the
>>>> docker daemon params some labels exposing availability zone or other
>>>> metadata (taken from the nova metadata).
>>>>
>>>> https://docs.docker.com/engine/userguide/labels-custom-metadata/#daemon-labels
>>>>
>>>> It's a bit less clear how we would get heat to launch nodes across
>>>> availability zones using ResourceGroup(s), but there are other heat
>>>> resources that support it (i'm sure this can be done).
>>>>
>>>> Does this make sense? Any thoughts or alternatives?
>>>>
>>>> If it makes sense i'm happy to submit a blueprint.
>>>>
>>>> Cheers,
>>>> Ricardo
>>>>
>>>>
>>>> __________________________________________________________________________
>>>> 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
More information about the OpenStack-dev
mailing list