Your understanding is correct. I have the same problem as well. For now, my plan is to just move cinder-volume to our more robust hosts, and run database changes to modify the host, as needed.
I have noticed a growing trend to replace the host parameter with a generic, but I agree that this presents other problems as well. This option may be just as problematic as having to modify the database in the event of a cinder-volume host outage. Probably worth having a discussion with the Cinder dev community. -- Warren Warren On Wed, Jan 7, 2015 at 8:42 AM, Arne Wiebalck <[email protected]> wrote: > Hi, > > Will a Cinder volume creation request ever timeout and be rescheduled in > case the host with the volume service it has been scheduled to is not > consuming the corresponding message? > > Similarly: if the host the volume has been created on and to which later > the deletion request is scheduled has disappeared (e.g. meanwhile retired), > will the scheduler try to schedule to another host? > > From what I see, the answer to both of these questions seems to be ’no'. > Things can get stuck in these scenarios and can only be unblocked by > resurrecting the down host or by manually changing the Cinder database. > > Is my understanding correct? > > Is there a way to tag hosts so that any of my Cinder hosts can pick up the > creation (and in particular deletion) message? I tried with the “host” > parameter in cinder.conf which seems to “work", but is probably not meant > for this, in particular as it touches the services database and makes the > hosts indistinguishable > (which in turn breaks cinder-manage). > > How do people deal with this issue? > > Thanks! > Arne > > — > Arne Wiebalck > CERN IT > > > > > _______________________________________________ > OpenStack-operators mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >
_______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
