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 <[email protected]> wrote: > > > On Mon, Aug 10, 2015 at 9:24 AM, Dulko, Michal <[email protected]> > 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/api/create_volume.py#L279-L282 >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> [email protected]?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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
