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.openst...@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.o...@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.po...@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-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