Open Stack

Thanks for your feedback. 

Sandy, thank you for the link. I agree that the .start/.end 
notification pattern that you propose seems to be the most appropriate 
to monitor actions launched through the Horizon dashboard. 

In the case of .start/.end notifications, the decorator should do the 
job and has the advantage of being less intrusive than the function 
call. Specific notifications may then be sent through ad-hoc 
functions. 

Lance, I agree with you that generic notification patterns should be 
moved to Oslo-incubator. While Keystone's `notifications.py` module 
implements the CrUD pattern, I believe that the .start/.end pattern 
makes more sense in the case of Horizon. 

I'll try and propose a generic .start/.end pattern implementation to 
the Oslo-incubator, that will be based on Keystone's decorator 
implementation. 

Regards, 
Florent Flament 

----- Original Message -----

From: "Lance D Bragstad" <ldbragst at us.ibm.com> 
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org> 
Sent: Monday, November 25, 2013 6:21:55 PM 
Subject: Re: [openstack-dev] Adding notifications to Horizon 



Sandy Walsh <sandy.walsh at rackspace.com> wrote on 11/25/2013 10:30:05 AM: 

> From: Sandy Walsh <sandy.walsh at rackspace.com> 
> To: <openstack-dev at lists.openstack.org>, 
> Date: 11/25/2013 10:34 AM 
> Subject: Re: [openstack-dev] Adding notifications to Horizon 
> 
> +1 on the inline method. It makes it clear when a notification should be 
> emitted and, as you say, handles the exception handling better. 

This might be a good opportunity to add the decorator from Keystone's 
notification module to Oslo-incubator, and recycle some of that code. 

https://github.com/openstack/keystone/blob/master/keystone/notifications.py#L26 

I know some projects may require more information to be sent in the event payload: 
https://github.com/openstack/nova/blob/master/nova/compute/api.py#L783 

but a general case (like Keystone) that requires only a UUID of the resource 
and the type of action being created, the current decorator does this pretty well. 
https://github.com/openstack/keystone/blob/master/keystone/assignment/core.py#L66 

If this is the direction of event notifications in Horizon, it would be nice to 
settle on one implementation. 

> 
> Also, if it makes sense for Horizon, consider bracketing long-running 
> operations in .start/.end pairs. This will help with performance tuning 
> and early error detection. 
> 
> More info on "well behaved notifications" in here: 
> http://www.sandywalsh.com/2013/09/notification-usage-in-openstack-report.html 
> 
> Great to see! 
> 
> -S 
> 
> 
> On 11/25/2013 11:58 AM, Florent Flament wrote: 
> > Hi, 
> > 
> > I am interested in adding AMQP notifications to the Horizon dashboard, 
> > as described in the following blueprint: 
> > https://blueprints.launchpad.net/horizon/+spec/horizon-notifications 
> > 
> > There are currently several implementations in Openstack. While 
> > Nova and Cinder define `notify_about_*` methods that are called 
> > whenever a notification has to be sent, Keystone uses decorators, 
> > which send appropriate notifications when decorated methods are 
> > called. 
> > 
> > I fed the blueprint's whiteboard with an implementation proposal, 
> > based on Nova and Cinder implementation. I would be interested in 
> > having your opinion about which method would fit best, and whether 
> > these notifications make sense at all. 
> > 
> > Cheers, 
> > Florent Flament 
> > 
> > _______________________________________________ 
> > OpenStack-dev mailing list 
> > OpenStack-dev at lists.openstack.org 
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> > 
> 
> _______________________________________________ 
> OpenStack-dev mailing list 
> OpenStack-dev at lists.openstack.org 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 



Best Regards, 

Lance Bragstad 

_______________________________________________ 
OpenStack-dev mailing list 
OpenStack-dev at lists.openstack.org 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131126/9abc8ff3/attachment.html>