[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