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.
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 On 28 Aug 2015 11:59, "Dulko, Michal" <michal.du...@intel.com> wrote: > > From: Ben Swartzlander [mailto:b...@swartzlander.org] > > Sent: Thursday, August 27, 2015 8:11 PM > > To: OpenStack Development Mailing List (not for usage questions) > > > > On 08/27/2015 10:43 AM, Ivan Kolodyazhny wrote: > > > > > > Hi, > > > > Looks like we need to be able to set AZ per backend. What do you > > think about such option? > > > > > > > > I dislike such an option. > > > > The whole premise behind an AZ is that it's a failure domain. The node > > running the cinder services is in exactly one such failure domain. If > you have 2 > > backends in 2 different AZs, then the cinder services managing those > > backends should be running on nodes that are also in those AZs. If you > do it > > any other way then you create a situation where a failure in one AZ > causes > > loss of services in a different AZ, which is exactly what the AZ feature > is trying > > to avoid. > > > > If you do the correct thing and run cinder services on nodes in the AZs > that > > they're managing then you will never have a problem with the one-AZ-per- > > cinder.conf design we have today. > > > > -Ben > > 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. > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
