<html><head><title></title></head><body><!-- rte-version 0.2 9947551637294008b77bce25eb683dac --><div class="rte-style-maintainer" style="white-space: pre-wrap; font-size: small; font-family: 'Courier New', Courier; color: rgb(0, 0, 0);"data-color="global-default" bbg-color="default" data-bb-font-size="medium" bbg-font-size="medium" bbg-font-family="fixed-width">Our use case for fake AZs (and why I pushed <a spellcheck="false"href="https://review.openstack.org/#/c/217857/" bbg-destination="rte:bind" data-destination="rte:bind">https://review.openstack.org/#/c/217857/</a> to enable that sort of behavior) is what Michal outlined, namely that we use Ceph and do not need or want Cinder to add itself to the mix when we're dealing with our failure domains. We already handle that via our Ceph crush map, so Cinder doesn't need to worry about it. It should just throw volumes at the configured RBD pool for the requested backend and not concern itself with what's going on behind the scenes.<br><div class="rte-style-maintainer" style="font-size: small; font-family: 'Courier New', Courier; color: rgb(0, 0, 0);"data-color="global-default" bbg-color="default" data-bb-font-size="medium" bbg-font-size="medium" bbg-font-family="fixed-width"><br><div class="bbg-rte-fold-content" data-header="From: openstack-dev@lists.openstack.org" data-digest="From: openstack-dev@lists.openstack.org" style=""><div class="bbg-rte-fold-summary">From: openstack-dev@lists.openstack.org </div><div>Subject: Re: [openstack-dev] [cinder] [nova] Cinder and Nova availability zones<br></div></div><div class="rte-internet-block-wrapper" style="color: black; font-family: Arial, 'BB.Proportional'; font-size: small; white-space: normal; background: white;"><div class="rte-internet-block"><blockquote><p dir="ltr">Except your failure domain includes the cinder volume service, independent of the resiliency of you backend, so if they're all on one node then you don't really have availability zones.</p><p dir="ltr">I have historically strongly espoused the same view as Ben, though there are lots of people who want fake availability zones... No strong use cases though</p><div class="gmail_quote">On 28 Aug 2015 11:59, "Dulko, Michal" <<a href="mailto:michal.dulko@intel.com" spellcheck="false" bbg-destination="mailto:rte:bind" class="" data-destination="mailto:rte:bind">michal.dulko@intel.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> From: Ben Swartzlander [mailto:<a href="mailto:ben@swartzlander.org"spellcheck="false" bbg-destination="mailto:rte:bind" class="rte-from-internet" data-destination="mailto:rte:bind">ben@swartzlander.org</a>]<br>> Sent: Thursday, August 27, 2015 8:11 PM<br>> To: OpenStack Development Mailing List (not for usage questions)<br>><br>> On 08/27/2015 10:43 AM, Ivan Kolodyazhny wrote:<br>><br>><br>>       Hi,<br>><br>>       Looks like we need to be able to set AZ per backend. What do you<br>> think about such option?<br>><br>><br>><br>> I dislike such an option.<br>><br>> The whole premise behind an AZ is that it's a failure domain. The node<br>> running the cinder services is in exactly one such failure domain. If you have 2<br>> backends in 2 different AZs, then the cinder services managing those<br>> backends should be running on nodes that are also in those AZs. If you do it<br>> any other way then you create a situation where a failure in one AZ causes<br>> loss of services in a different AZ, which is exactly what the AZ feature is trying<br>> to avoid.<br>><br>> If you do the correct thing and run cinder services on nodes in the AZs that<br>> they're managing then you will never have a problem with the one-AZ-per-<br>> cinder.conf design we have today.<br>><br>> -Ben<br><br>I disagree. You may have failure domains done on a different level, like using Ceph mechanisms for that. In such case you want to provide the user with a single backend regardless of compute AZ partitioning. To address such needs you would need to set multiple AZ per backend to make this achievable.<br><br>__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: <a href="OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"spellcheck="false" bbg-destination="rte:bind" class=""data-destination="rte:bind">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"spellcheck="false" bbg-destination="rte:bind" class="rte-from-internet" data-destination="rte:bind">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br></blockquote></div><div style="width: 500px; font-style:oblique; margin: 14px; margin-left: 0px; padding-top: 4px; border-top: 1px dotted black"></div><pre>__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
</pre></blockquote><br></div></div></div></div></body></html>