<div dir="ltr">I think there is a lot to discuss here and I would love to push for a solution implemented in Liberty. I have a proposed summit session on this topic (Asynchrounous Error Reporting). I also discussed this briefly at the Kilo summit. I will work on formalizing some of these ideas and hopefully we can pick a path forward at the summit.<div><br></div><div>Keep the discussion going :) I will try to organize everyones thoughts.<br><div><br></div><div>-Alex</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 13, 2015 at 10:00 AM, Erlon Cruz <span dir="ltr"><<a href="mailto:sombrafam@gmail.com" target="_blank">sombrafam@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I like Duncan's idea. To have a dash in horizon where admin can see error events. It can hide backend details from tenants and  would save the time of browsing through logs seeking for the operations that  caused errors (the request id also should be logged in the metadata to allow further investigation). We have notice this problem while ago, and at the time we found this bug[1] about the same problem.<div><br></div><div>[1] <a href="https://bugs.launchpad.net/horizon/+bug/1352516" target="_blank">https://bugs.launchpad.net/horizon/+bug/1352516</a><br><div><div><br></div></div></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 10, 2015 at 5:26 PM, gordon chung <span dir="ltr"><<a href="mailto:gord@live.ca" target="_blank">gord@live.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>> I'd say events are *more* useful in that workflow, not less, as long as<br>
> they contain enough context. For example, the user creates a volume,<br>
> tries to attach it which fails for some config error, so the user<br>
> deletes it. With an event based model, the admin now has an error event<br>
> in their queue. If we used a db field then the error status is<br>
> potentially revived by the successful delete.<br>
<br>
</span>+1<br>
<br>
Nova currently emits a good set of events and errors and we've found it especially useful to debug / do postmortem analysis by collecting these notifications and being able to view the entire workflow. we've found quite a few occasions where the error popups presented in Horizon are not the real error but just the last/wrapped error.<br>
<br>
there are various consumers that already collate these error notifications from Nova and i don't think it's much of a change if any to collect error notifications from Cinder. i don't think there's any change from Ceilometer POV -- just publish to error topic.<br>
<br>
cheers,<br>
<br>
gord<br>
<div><div><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>