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" <[email protected]> To: "OpenStack Development Mailing List (not for usage questions)" <[email protected]> Sent: Monday, November 25, 2013 6:21:55 PM Subject: Re: [openstack-dev] Adding notifications to Horizon Sandy Walsh <[email protected]> wrote on 11/25/2013 10:30:05 AM: > From: Sandy Walsh <[email protected]> > To: <[email protected]>, > 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 > > [email protected] > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > Best Regards, Lance Bragstad _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
