<div dir="ltr">+1 for Phil comments.<div><div>I agree that VMs should spread between different default avzs if user doesn't define one at boot time.</div><div>There is a blueprint for that feature that unfortunately didn't make it for icehouse.</div>
<div><a href="https://blueprints.launchpad.net/nova/+spec/schedule-set-availability-zones">https://blueprints.launchpad.net/nova/+spec/schedule-set-availability-zones</a><br></div><div><br></div><div>Belmiro</div><div><br>
</div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Mar 28, 2014 at 12:01 PM, Day, Phil <span dir="ltr"><<a href="mailto:philip.day@hp.com" target="_blank">philip.day@hp.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">>> Personally, I feel it is a mistake to continue to use the Amazon concept<br>

>> of an availability zone in OpenStack, as it brings with it the<br>
>> connotation from AWS EC2 that each zone is an independent failure<br>
>> domain. This characteristic of EC2 availability zones is not enforced in<br>
>> OpenStack Nova or Cinder, and therefore creates a false expectation for<br>
>> Nova users.<br>
<br>
>I think this is backwards training, personally. I think azs as separate failure<br>
>domains were done like that for a reason by amazon, and make good sense.<br>
>What we've done is overload that with cells, aggregates etc which should<br>
>have a better interface and are a different concept. Redefining well understood<br>
>terms because they don't suite your current implementation is a slippery slope,<br>
>and overloading terms that already have a meaning in the industry in just annoying.<br>
<br>
</div></div>+1<br>
I don't think there is anything wrong with identifying new use cases and working out how to cope with them:<br>
<br>
 - First we generalized Aggregates<br>
- Then we mapped AZs onto aggregates as a special mutually exclusive group<br>
- Now we're recognizing that maybe we need to make those changes to support AZs more generic so we can create additional groups of mutually exclusive aggregates<br>
<br>
That all feels like good evolution.<br>
<br>
But I don't see why that means we have to fit that in under the existing concept of AZs - why can't we keep AZs as they are and have a better thing called Zones that is just an OSAPI concept and is better that AZs ?    Arguments around not wanting to add new options to create server seem a bit weak to me - for sure we don't want to add them in an uncontrolled way, but if we have a new, richer, concept we should be able to express that separately.<br>

<br>
I'm still not personally convinced by the need use cases of racks having orthogonal power failure domains and switch failure domains - that seems to me from a practical perspective that it becomes really hard to work out where to separate VMs so that they don't share a failure mode.    Every physical DC design I've been involved with tries to get the different failure domains to align.   However if it the use case makes sense to someone then I'm not against extending aggregates to support multiple mutually exclusive groups.<br>

<br>
I think I see a Design Summit session emerging here<br>
<span class="HOEnZb"><font color="#888888"><br>
Phil<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">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>
</div></div></blockquote></div><br></div>