Open Stack

+1 in that we experienced this as well.   We implemented an HA iscsi cinder and failover from one node to the other works great until you have to do some administrative action on the volume and the mismatched name in the database messes that up.  We’ve had to change hostnames in the DB or fail back to make it work.  We’ve been meaning to genericize the name on our side, just like we do for nova with the nova-network host



On Jan 7, 2015, at 9:45 AM, Amit Das <amit.das at cloudbyte.com<mailto:amit.das at cloudbyte.com>> wrote:


+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" <warren at wangspeed.com<mailto:warren at wangspeed.com>> 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 <Arne.Wiebalck at cern.ch<mailto: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<mailto:OpenStack-operators at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


________________________________

CONFIDENTIALITY NOTICE: This message is intended only for the use and review of the individual or entity to which it is addressed and may contain information that is privileged and confidential. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message solely to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify sender immediately by telephone or return email. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150107/b4e8d519/attachment.html>