The problem is that the scheduler doesn't currently have enough info to know which backends are 'equivalent' and which aren't. e.g. If you have 2 ceph clusters as cinder backends, they are indistinguishable from each other.
On 8 January 2015 at 12:14, Arne Wiebalck <arne.wieba...@cern.ch> wrote: > Hi, > > The fact that volume requests (in particular deletions) are coupled with > certain Cinder hosts is not ideal from an operational perspective: > if the node has meanwhile disappeared, e.g. retired, the deletion gets > stuck and can only be unblocked by changing the database. Some > people apparently use the ‘host’ option in cinder.conf to make the hosts > indistinguishable, but this creates problems in other places. > > From what I see, even for backends that would support it (such as Ceph), > Cinder currently does not provide means to ensure that any of > the hosts capable of performing a volume operation would be assigned the > request in case the original/desired one is no more available, > right? > > If that is correct, how about changing the scheduling of delete operation > to use the same logic as create operations, that is pick any of the > available hosts, rather than the one which created a volume in the first > place (for backends where that is possible, of course)? > > Thanks! > Arne > > — > Arne Wiebalck > CERN IT > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Duncan Thomas
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
