There were a little IRC discussion on that [1] and I've started to work on creating a spec for Mitaka. I've got a little busy last time, but finishing it is still in my backlog. I'll make sure to post it up for reviews once Mitaka specs bucket will open.
[1] http://eavesdrop.openstack.org/irclogs/%23openstack-cinder/%23openstack-cinder.2015-08-11.log.html#t2015-08-11T14:48:49 > -----Original Message----- > From: Ivan Kolodyazhny [mailto:e...@e0ne.info] > Sent: Thursday, August 27, 2015 4:44 PM > To: OpenStack Development Mailing List (not for usage questions) > Cc: Rogon, Kamil > Subject: Re: [openstack-dev] [cinder] [nova] Cinder and Nova availability > zones > > Hi, > > Looks like we need to be able to set AZ per backend. What do you think > about such option? > > > Regards, > Ivan Kolodyazhny > > On Mon, Aug 10, 2015 at 7:07 PM, John Griffith <john.griffi...@gmail.com > <mailto:john.griffi...@gmail.com> > wrote: > > > > > On Mon, Aug 10, 2015 at 9:24 AM, Dulko, Michal > <michal.du...@intel.com <mailto:michal.du...@intel.com> > wrote: > > > Hi, > > In Kilo cycle [1] was merged. It started passing AZ of a booted > VM to Cinder to make volumes appear in the same AZ as VM. This is certainly > a good approach, but I wonder how to deal with an use case when > administrator cares about AZ of a compute node of the VM, but wants to > ignore AZ of volume. Such case would be when fault tolerance of storage is > maintained on another level - for example using Ceph replication and failure > domains. > > Normally I would simply disable AvailabilityZoneFilter in > cinder.conf, but it turns out cinder-api validates if availability zone is > correct > [2]. This means that if Cinder has no AZs configured all requests from Nova > will fail on an API level. > > Configuring fake AZs in Cinder is also problematic, because AZ > cannot be configured on a per-backend manner. I can only configure it per c- > vol node, so I would need N extra nodes running c-vol, where N is number > of AZs to achieve that. > > Is there any solution to satisfy such use case? > > [1] https://review.openstack.org/#/c/157041 > [2] > https://github.com/openstack/cinder/blob/master/cinder/volume/flows/ap > i/create_volume.py#L279-L282 > > > ____________________________________________________ > ______________________ > OpenStack Development Mailing List (not for usage > questions) > Unsubscribe: OpenStack-dev- > requ...@lists.openstack.org?subject:unsubscribe <http://OpenStack-dev- > requ...@lists.openstack.org?subject:unsubscribe> > http://lists.openstack.org/cgi- > bin/mailman/listinfo/openstack-dev > > > > ​Seems like we could introduce the capability in cinder to ignore that > if > it's desired? It would probably be worth looking on the Cinder side at being > able to configure multiple AZ's for a volume (perhaps even an aggregate > Zone just for Cinder). That way we still honor the setting but provide a way > to get around it for those that know what they're doing. > > > John > > > ____________________________________________________ > ______________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev- > requ...@lists.openstack.org?subject:unsubscribe <http://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
