<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2014-04-04 10:30 GMT+02:00 Sylvain Bauza <span dir="ltr"><<a href="mailto:sylvain.bauza@gmail.com" target="_blank">sylvain.bauza@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi all,<div><br></div><div class="gmail_extra">
<br><br><div class="gmail_quote">2014-04-03 18:47 GMT+02:00 Meghal Gosalia <span dir="ltr"><<a href="mailto:meghal@yahoo-inc.com" target="_blank">meghal@yahoo-inc.com</a>></span>:<div><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word">
Hello folks,
<div><br>
</div>
<div>Here is the bug [1] which is currently not allowing a host to be part of two availability zones.</div>
<div>This bug was targeted for havana.</div>
<div><br>
</div>
<div>The fix in the bug was made because it was assumed </div>
<div>that openstack does not support adding hosts to two zones by design. </div>
<div><br>
</div>
<div>The assumption was based on the fact that ---</div>
<div>if hostX is added to zoneA as well as zoneB,</div>
<div>and if you boot a vm vmY passing zoneB in boot params,</div>
<div>nova show vmY still returns zoneA. </div>
<div><br>
</div>
<div>In my opinion, we should fix the case of nova show </div>
<div>rather than changing aggregate api to not allow addition of hosts to multiple zones.</div>
<div><br>
</div>
<div>I have added my comments in comments #7 and #9 on that bug.</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Meghal</div>
<div> <br></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word">
<div>
</div>
<div>[1] Bug - <a href="https://bugs.launchpad.net/nova/+bug/1196893" target="_blank">https://bugs.launchpad.net/nova/+bug/1196893</a></div><div><div>
<div><br>
</div>
<div><br></div></div></div></div></blockquote><div><br></div><div><br></div><div><br></div></div><div>Thanks for the pointer, now I see why the API is preventing host to be added to a 2nd aggregated if there is a different AZ. Unfortunately, this patch missed the fact that aggregates metadata can be modified once the aggregate is created, so we should add a check when updating metadate in order to cover all corner cases.</div>
<div><br></div><div>So, IMHO, it's worth providing a patch for API consistency so as we enforce the fact that a host should be in only one AZ (but possibly 2 or more aggregates) and see how we can propose to user ability to provide 2 distincts AZs when booting.</div>
<div><br></div><div>Does everyone agree ?</div><span><font color="#888888"><div><br></div></font></span></div></div></div></blockquote><div><br></div><div><br></div><div><br></div><div>Well, I'm replying to myself. The corner case is even trickier. I missed this patch [1] which already checks that when updating an aggregate to set an AZ, its hosts are not already part of another AZ. So, indeed, the coverage is already there... except for one thing :</div>
<div><br></div><div>If an operator is creating an aggregate with an AZ set to the default AZ defined in nova.conf and adds an host to this aggregate, nova availability-zone-list does show the host being part of this default AZ (normal behaviour). If we create an aggregate 'foo' without AZ, then we add the same host to that aggregate, and then we update the metadata of the aggregate to set an AZ 'foo', then the AZ check won't notice that the host is already part of an AZ and will allow the host to be part of two distinct AZs.</div>
<div><br></div><div>Proof here : <a href="http://paste.openstack.org/show/75066/">http://paste.openstack.org/show/75066/</a></div><div><br></div><div>I'm on that bug.</div><div>-Sylvain</div><div><br></div><div>[1] : <a href="https://review.openstack.org/#/c/36786" target="_blank">https://review.openstack.org/#/c/36786</a> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><font color="#888888"><div></div><div>-Sylvain</div></font></span><div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div><div><div>
</div>
<div>
<div>
<div>On Apr 3, 2014, at 9:05 AM, Steve Gordon <<a href="mailto:sgordon@redhat.com" target="_blank">sgordon@redhat.com</a>> wrote:</div>
<br>
<blockquote type="cite">----- Original Message -----<br>
<br>
<blockquote type="cite">Currently host aggregates are quite general, but the only ways for an<br>
end-user to make use of them are:<br>
<br>
1) By making the host aggregate an availability zones (where each host<br>
is only supposed to be in one availability zone) and selecting it at<br>
instance creation time.<br>
<br>
2) By booting the instance using a flavor with appropriate metadata<br>
(which can only be set up by admin).<br>
<br>
<br>
I would like to see more flexibility available to the end-user, so I<br>
think we should either:<br>
<br>
A) Allow hosts to be part of more than one availability zone (and allow<br>
selection of multiple availability zones when booting an instance), or<br>
</blockquote>
<br>
While changing to allow hosts to be in multiple AZs changes the concept from an operator/user point of view I do think the idea of being able to specify multiple AZs when booting an instance makes sense and would be a nice enhancement for users working with
multi-AZ environments - "I'm OK with this instance running in AZ1 and AZ2, but not AZ*".<br>
<br>
-Steve<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
</div>
<br>
</div>
</div></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div></div><br></div></div>
</blockquote></div><br></div></div>