No error displayed on volume attachment fail (need to get errors that happen after initial response)

Bug #970693 reported by Tihomir Trifonov
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Opinion
Wishlist
Unassigned

Bug Description

When trying to attach a volume over existing device (i.e we have an instance with disk volume, and we try to attach another volume on /dev/hda) :

http://db.tt/OzTWgDJR

The operation finished without the actual error, just the notification above for starting the process. In the table below the status changes from 'Attaching' back to 'Available'. without showing a reason for attachment failure reason.

Tags: volume
Devin Carlen (devcamcar)
Changed in horizon:
status: New → Confirmed
importance: Undecided → Medium
milestone: none → folsom-1
Revision history for this message
Stanisław Jankowski (staszek) wrote :

We have the same issue. The volume can be only managed using command-line and ID. When we are trying to use volume name (while deleting/attaching volume) then we have the same error as above.

Revision history for this message
Gabriel Hurley (gabriel-hurley) wrote :

In order to do this we need a way to be notified by Glance of failures that happen *after* the initial response. Until then, Horizon is basically incapable of finding out what the error was.

Revision history for this message
Eoghan Glynn (eglynn) wrote :

Gabriel - did you mean some way of being notified by nova-volume of attachment failures (as opposed to be notified by glance)?

Revision history for this message
Brian Waldon (bcwaldon) wrote :

Eoghan: I believe he did. Replaced Glance target with Nova.

no longer affects: glance
Devin Carlen (devcamcar)
Changed in horizon:
assignee: nobody → Nebula (nebula)
Devin Carlen (devcamcar)
Changed in horizon:
milestone: folsom-1 → folsom-2
Thierry Carrez (ttx)
summary: - No error is displayed on volume attachment failure
+ No error displayed on volume attachment fail (need to get errors that
+ happen after initial response)
Changed in nova:
importance: Undecided → Wishlist
status: New → Confirmed
tags: added: volume
Revision history for this message
Gabriel Hurley (gabriel-hurley) wrote :

Since this is unassigned and wishlisted in Nova, there's nothing Horizon can do. Bumping this out of any milestone. We may get around to solving realtime communications before nova actually does anything about this...

Changed in horizon:
assignee: Nebula (nebula) → Gabriel Hurley (gabriel-hurley)
milestone: folsom-2 → none
Changed in horizon:
importance: Medium → Wishlist
Revision history for this message
David Lyle (david-lyle) wrote :

I believe this has been resolved in cinder as I get error messages when volume attachments fail.

Revision history for this message
Yehia Beyh (yehia-beyh) wrote :

Cinder did not solve this issue. The problem is that the nova-attach is an asyn call. when you call nova-attach it returns OK (200). Then the process of attaching begins. If any failure occurs, horizon does not know how to track the task thus the error which cinder raises will be lost. Either nova or horizon need to change to track any errors so the failure is not silent.

Revision history for this message
haruka tanizawa (h-tanizawa) wrote :

How about using TaskAPI which can track request about instance?

Revision history for this message
Markus Zoeller (markus_z) (mzoeller) wrote :

This wishlist bug has been open a year without any activity. I'm going to move it to "Opinion / Wishlist", which is an easily-obtainable queue of older requests that have come on. This bug can be reopened (set back to "New") if someone decides to work on this.

Changed in nova:
status: Confirmed → Opinion
Revision history for this message
Akihiro Motoki (amotoki) wrote :

Horizon side depends on Nova change and there seems no activity in nova side. We, horizon team, remove horizon from the affected project and would like to file a bug or a feature request once nova supports some kind of feature on this.

no longer affects: horizon
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.