<div dir="ltr">+1 from me too for the idea. Please file a blueprint. Seems feasible and useful.<div><br></div><div>-Vilobh<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 23, 2016 at 7:25 PM, Adrian Otto <span dir="ltr"><<a href="mailto:adrian.otto@rackspace.com" target="_blank">adrian.otto@rackspace.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ricardo,<br>
<br>
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.<br>
<span class="HOEnZb"><font color="#888888"><br>
Adrian<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> On Feb 23, 2016, at 4:11 PM, Ricardo Rocha <<a href="mailto:rocha.porto@gmail.com">rocha.porto@gmail.com</a>> wrote:<br>
><br>
> Hi.<br>
><br>
> Has anyone looked into having magnum bay nodes deployed in different<br>
> availability zones? The goal would be to have multiple instances of a<br>
> container running on nodes across multiple AZs.<br>
><br>
> Looking at docker swarm this could be achieved using (for example)<br>
> affinity filters based on labels. Something like:<br>
><br>
> docker run -it -d -p 80:80 --label nova.availability-zone=my-zone-a nginx<br>
> <a href="https://docs.docker.com/swarm/scheduler/filter/#use-an-affinity-filter" rel="noreferrer" target="_blank">https://docs.docker.com/swarm/scheduler/filter/#use-an-affinity-filter</a><br>
><br>
> We can do this if we change the templates/config scripts to add to the<br>
> docker daemon params some labels exposing availability zone or other<br>
> metadata (taken from the nova metadata).<br>
> <a href="https://docs.docker.com/engine/userguide/labels-custom-metadata/#daemon-labels" rel="noreferrer" target="_blank">https://docs.docker.com/engine/userguide/labels-custom-metadata/#daemon-labels</a><br>
><br>
> It's a bit less clear how we would get heat to launch nodes across<br>
> availability zones using ResourceGroup(s), but there are other heat<br>
> resources that support it (i'm sure this can be done).<br>
><br>
> Does this make sense? Any thoughts or alternatives?<br>
><br>
> If it makes sense i'm happy to submit a blueprint.<br>
><br>
> Cheers,<br>
>  Ricardo<br>
><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>
__________________________________________________________________________<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>
</div></div></blockquote></div><br></div></div></div>