Bug 1410704 - Missing fail reason description - creation of volume fails show an error message in horizon.
Summary: Missing fail reason description - creation of volume fails show an error mess...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: python-django-horizon
Version: 8.0 (Liberty)
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: Upstream M2
: 12.0 (Pike)
Assignee: Radomir Dopieralski
QA Contact: Ido Ovadia
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-06 06:40 UTC by Nilesh
Modified: 2020-05-14 15:31 UTC (History)
13 users (show)

Fixed In Version: python-django-horizon-12.0.0-0.20170624124155.e8d1dd9.el7ost
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-12-13 20:57:54 UTC
Target Upstream Version:
nchandek: automate_bug?
pm-rhel: internal-review+


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Launchpad 1352516 None None None 2017-03-09 12:55:56 UTC
Red Hat Product Errata RHEA-2017:3462 normal SHIPPED_LIVE Red Hat OpenStack Platform 12.0 Enhancement Advisory 2018-02-16 01:43:25 UTC

Description Nilesh 2017-01-06 06:40:30 UTC
Description of problem:

The creation of volume fails as it should, but there is no description of the fail reason in the horizon GUI. 

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:

1. Create image - using rhel_6_5_v20 => QCOW, size 1.1G.
2. Create volume with that image as its source, with size 4G.
3. See that the volume creation fails -> state = error. But there is no explanation of why.


This is expected, but Horizon should gives an error message on GUI. 

Actual results:

Horizon should be show reported error message in GUI. 

Expected results:

Horizon should be show reported error message in GUI. 

Additional info:

Comment 1 Eric Harney 2017-01-06 14:08:28 UTC
This is a known limitation, currently.

Cinder now has an API which can be used to retrieve messages for this type of failure after the request fails, but it does not generate messages for a lot of failure cases yet.

Horizon will need to query this API and report messages to the user.

I will gather some information on this before filing a bug against Horizon.

Comment 2 Nilesh 2017-01-06 14:11:47 UTC
(In reply to Eric Harney from comment #1)
> This is a known limitation, currently.
> 
> Cinder now has an API which can be used to retrieve messages for this type
> of failure after the request fails, but it does not generate messages for a
> lot of failure cases yet.
> 
> Horizon will need to query this API and report messages to the user.
> 
> I will gather some information on this before filing a bug against Horizon.

Thank you, Eric. I will wait for more information.

Comment 6 Eric Harney 2017-01-31 19:36:37 UTC
The request here is to add Horizon support for Cinder async error messages.  This will give users the ability to more information about why a Cinder operation failed.

The basic test path from the Cinder CLI is:

$ export OS_VOLUME_API_VERSION=3.5
$ cinder --debug create 900
$ cinder show <id>
  -> status is "error"
$ cinder message-list --resource_uuid <id> --resource_type volume

This will show the error message indicating that the request failed due to an inability to allocate storage.  It is also possible to search using the request id of the operation that failed rather than the volume id.

Horizon should retrieve these messages from the Cinder API when appropriate (i.e. user requests volume creation and the operation fails) and display them in the UI.

Cinder devref:  http://docs.openstack.org/developer/cinder/devref/user_messages.html

Comment 7 Nilesh 2017-02-01 05:41:47 UTC
(In reply to Eric Harney from comment #6)
> The request here is to add Horizon support for Cinder async error messages. 
> This will give users the ability to more information about why a Cinder
> operation failed.
> 
> The basic test path from the Cinder CLI is:
> 
> $ export OS_VOLUME_API_VERSION=3.5
> $ cinder --debug create 900
> $ cinder show <id>
>   -> status is "error"
> $ cinder message-list --resource_uuid <id> --resource_type volume
> 
> This will show the error message indicating that the request failed due to
> an inability to allocate storage.  It is also possible to search using the
> request id of the operation that failed rather than the volume id.
> 
> Horizon should retrieve these messages from the Cinder API when appropriate
> (i.e. user requests volume creation and the operation fails) and display
> them in the UI.
> 
> Cinder devref: 
> http://docs.openstack.org/developer/cinder/devref/user_messages.html

Thank you, Eric for the clarification and letting know the procedure, Could we integrate this feature in the GUI, So that Customers can see the failed message.

Comment 8 Radomir Dopieralski 2017-02-01 08:19:25 UTC
Horizon is a stateless web application. We don't have our own database or long-running processes -- we only get data by calling the various APIs of other projects, and we only get to run code when a user makes a request. This means that there is currently no way for Horizon to "remember" that there is a Cinder operation pending, continuously poll for its status, and display the error to the user across different views in Horizon. The only way we could do it is by making the user stay on a single view showing the status of the operation, which we could then periodically refresh.

Comment 9 Nilesh 2017-02-05 06:25:23 UTC
Thank you, Radomir Dopieralski. So this can not be fix in the customer running environment ?

Comment 10 Radomir Dopieralski 2017-02-07 07:23:23 UTC
Not the way it is requested here with the current state of Horizon. However, perhaps this customer problem can be solved in a different way -- for instance, by adding a view that shows all the pending operations and their statuses, or a log of recent operations and their status changes. This should probably be designed by the UX people in cooperation with the customer.

Comment 11 Radomir Dopieralski 2017-02-08 17:17:42 UTC
It has just be pointed to me, that in this case the fact of the error is already known to Horizon, as it does display an error message -- all that it needs to do is to retrieve the actual reason of the error. This is a different case, and that is certainly possible.

Comment 12 Nilesh 2017-02-09 07:45:05 UTC
Yes. It just needs to do is retrieve the actual reason of the error and display to the horizon dashboard.

Comment 13 Radomir Dopieralski 2017-02-09 08:30:59 UTC
Thank you for confirming.

Comment 14 Nilesh 2017-02-27 13:17:24 UTC
Hello, 

Do we have any update on the same. Cu is still waiting to know the progress. 

-Nilesh.

Comment 15 Radomir Dopieralski 2017-02-27 14:18:37 UTC
No progress, we worked on other, higher priority issues.

Comment 17 Radomir Dopieralski 2017-03-09 20:10:09 UTC
I'm still not entirely sure how to tackle this, but I think I will start by displaying all the messages for a given volume in its details view.

Comment 18 Radomir Dopieralski 2017-03-16 18:21:03 UTC
Here's a work-in-progress patch: https://review.openstack.org/446644

It's mostly complete, but there is just one small complication. This message API is only avaibale for Cinder v3, and at that, only at a certain microversion.

Since we don't yet support Cinder v3 or microversions in Horizon, this can't be merged.

Comment 19 Nilesh 2017-03-17 07:55:03 UTC
Hello Radomir, 

Thanks for the update, Do we have any plan to merge this in the future relases of OSP ? 

What we can update to customer ?

Comment 20 Radomir Dopieralski 2017-03-17 09:00:01 UTC
I think that we will add support for microversions to Horizon in this release -- the work on that started in OSP11, and I think it has very good chance of being finished soon. Once that's in, we can merge the support for the messages -- they will just require Cinder v3 to be enabled to work -- otherwise it will fall back to the old behavior.

There is a good chance of that landing in OSP12, however, we don't have full control over it, so there is a possibility it will get delayed and land in OSP13.

Comment 21 Radomir Dopieralski 2017-06-12 10:36:54 UTC
This just landed upstream and will be available in osp12.

Comment 26 errata-xmlrpc 2017-12-13 20:57:54 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2017:3462


Note You need to log in before you can comment on or make changes to this bug.