[openstack-dev] Adding notifications to Horizon
florent.flament-ext at cloudwatt.com
Tue Nov 26 15:02:55 UTC 2013
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
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
----- 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.
I know some projects may require more information to be sent in the event payload:
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.
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:
> Great to see!
> 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
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev