<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Sep 24, 2015 at 2:22 PM, Sam Morrison <span dir="ltr"><<a href="mailto:sorrison@gmail.com" target="_blank">sorrison@gmail.com</a>></span> wrote:<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"><span class=""><br></span><div>Yes an AZ may not be considered a failure domain in terms of control infrastructure, I think all operators understand this. If you want control infrastructure failure domains use regions.</div><div><br></div><div>However from a resource level (eg. running instance/ running volume) I would consider them some kind of failure domain. It’s a way of saying to a user if you have resources running in 2 AZs you have a more available service. </div><div><br></div><div>Every cloud will have a different definition of what an AZ is, a rack/collection of racks/DC etc. openstack doesn’t need to decide what that is.</div><span class=""><font color="#888888"><div><br></div><div>Sam</div></font></span></div></blockquote><div><br></div><div>This seems to map more closely to how we use AZs. </div><div><br></div><div>Turning it around to the user perspective: </div><div> My users want to be sure that when they boot compute resources, they can do so in such a way that their application will be immune to a certain amount of physical infrastructure failure. </div><div><br></div><div>Use cases I get from my users:</div><div>1. "I want to boot 10 instances, and be sure that if a single leg of power goes down, I wont lose more than 2 instances"</div><div>2. "My instances move a lot of network traffic. I want to ensure that I don't have more than 3 of my instances per rack, or else they'll saturate the ToR"</div><div>3. "Compute room #1 has been overrun by crazed ferrets. I need to boot new instances in compute room #2."</div><div>4. "I want to boot 10 instances, striped across at least two power domains, under no less than 5 top of rack switches, with access to network security zone X."</div><div><br></div><div>For my users, abstractions for availability and scale of the control plane should be hidden from their view. I've almost never been asked by my users whether or not the control plane is resilient. They assume that my team, as the deployers, have taken adequate steps to ensure that the control plane is deployed in a resilient and highly available fashion.</div><div><br></div><div>I think it would be good for the operator community to come to an agreement on what an AZ should be from the perspective of those who deploy both public and private clouds and bring that back to the dev teams.</div><div><br></div><div>-James</div><div>:)=</div></div></div></div>