+1 on the issue faced. We too had to use a generic name and modify db records to make this work. However we had to struggle for couple of days on a multi node setup before digging out the root cause.
Worth looping the dev group if they have some alternate suggestions. On 7 Jan 2015 20:45, "Warren Wang" <[email protected]> wrote: > 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 > >
_______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
