Open Stack

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 <Arne.Wiebalck at cern.ch> 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
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150107/8c558f58/attachment.html>