True. I was thinking more of the horizon event thing that show for a few seconds, then vanish. not useful for this case... Maybe something like the way heat keeps track of events, but more globally then? A list of error events in the admin tab that admins should look at and clear?
________________________________ From: Duncan Thomas Sent: Friday, April 10, 2015 12:52:21 PM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [cinder] Is there any way to put the driver backend error message to the horizon I'd say events are *more* useful in that workflow, not less, as long as they contain enough context. For example, the user creates a volume, tries to attach it which fails for some config error, so the user deletes it. With an event based model, the admin now has an error event in their queue. If we used a db field then the error status is potentially revived by the successful delete. Similarly if an intermittent fault happens but the action succeeds on a retry, then the error info is again lost. On 10 Apr 2015 20:45, "Fox, Kevin M" <kevin....@pnnl.gov<mailto:kevin....@pnnl.gov>> wrote: Events shouldnt help much since the workflow is, user does something. It breaks with "error notify admin" then admin needs to figure out why... ideally there needs to be a field for why in the db, and the dashboard can show it to admins? Thanks, Kevin ________________________________ From: Duncan Thomas Sent: Friday, April 10, 2015 11:47:07 AM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [cinder] Is there any way to put the driver backend error message to the horizon Maybe cinder can emit more notification events, then a dashboard can be build separately with the appropriate access control and filtering? The same dash can then be used for many projects - all they need to add are the events with enough metadata On 10 Apr 2015 18:53, "Ben Swartzlander" <b...@swartzlander.org<mailto:b...@swartzlander.org>> wrote: On 04/10/2015 08:11 AM, John Griffith wrote: On Fri, Apr 10, 2015 at 6:16 AM, liuxinguo <liuxin...@huawei.com<mailto:liuxin...@huawei.com>> wrote: Hi, When we create a volume in the horizon, there may occurrs some errors at the driver backend, and the in horizon we just see a “error” in the volume status. So is there any way to put the error information to the horizon so users can know what happened exactly just from the horizon? Thanks, Liu __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev The challenge here is that the calls to the driver are async, so we don't actually have any direct feedback/messages regarding the result. One thing that's been talked about in the past is adding additional information to the status which could be presented so that end users and tools like Horizon would have a little more information. The trick is however we also do NOT want driver info going back to the end user, the whole point of Cinder is to abstract all of that backend specific type stuff. The idea kicked around in the past was to introduce a sub-state with a bit more detail, but still wouldn't be anything specific from the driver. Sounds like a good topic to revisit for the Liberty release. Agreed that driver messages shouldn't reach the end user, but would it be helpful at all to the administrator to have driver error messages visible on the admin panel? -Ben __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
