Hi, >Some people apparently use the ‘host’ option in cinder.conf to make the hosts indistinguishable, but this creates problems in other places. I use shared storage mounted on several cinder-volume nodes, with "host" flag set the same everywhere. Never ran into problems so far. Could you elaborate on "this creates problems in other places" please ?
Thanks ! Jordan On Thu, Jan 8, 2015 at 3:40 PM, Arne Wiebalck <[email protected]> wrote: > Hmm. Not sure how widespread installations with multiple Ceph backends > are where the > Cinder hosts have access to only one of the backends (which is what you > assume, right?) > But, yes, if the volume type names are also the same (is that also needed > for this to be a > problem?), this will be an issue ... > > So, how about providing the information the scheduler does not have by > introducing an > additional tag to identify ‘equivalent’ backends, similar to the way some > people already > use the ‘host’ option? > > Thanks! > Arne > > > On 08 Jan 2015, at 15:11, Duncan Thomas <[email protected]> wrote: > > 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 <[email protected]> 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 >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > > -- > Duncan Thomas > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
