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:
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.
(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.
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
(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.
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.
Thank you, Radomir Dopieralski. So this can not be fix in the customer running environment ?
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.
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.
Yes. It just needs to do is retrieve the actual reason of the error and display to the horizon dashboard.
Thank you for confirming.
Hello, Do we have any update on the same. Cu is still waiting to know the progress. -Nilesh.
No progress, we worked on other, higher priority issues.
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.
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.
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 ?
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.
This just landed upstream and will be available in osp12.
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