Notifications between Aeolus components

Hugh Brock hbrock at redhat.com
Wed Jan 9 15:46:02 UTC 2013


On Wed, Jan 09, 2013 at 10:53:58AM +0000, Martyn Taylor wrote:
> On 01/08/2013 01:41 PM, Jan Provaznik wrote:
> >Hi folks,
> >I'd like to discuss a topic which was briefly touched on Aeolus
> >developer Conference in Brno. Many components of Aeolus project
> >need to send notifications to other components:
> >Heat -> Conductor (deployment/instance state changes)
> >Conductor -> Winged Monkey (deployment/instance state changes)
> >Imagefactory -> Conductor (notifications about image build&upload state)
> >DC tracker* -> Heat (notifications about instance state changes)
> >DC tracker -> Conductor (notifications about other provider
> >resource changes, realms availability, hw profile changes)
> >
> >* DC Tracker - this component is actually not agreed yet, it was
> >just a proposal some time ago, but I believe this will be needed.
> >
> >As far as I know there is no a unified plan how to deal with
> >notifications between components. At this point notifications are
> >implemented only in Imagefactory. This implementation is for now
> >quite simple - a notification callback is sent back as http PUT
> >request. It doesn't cover any failure situations (network error,
> >auth error, Conductor is not running...), so if a request is not
> >successful, no retry is done.
> >
> >I think we need more robust notification system between all
> >components above, this system should support at least:
> >1) retry on failure
> >2) keep correct order of notifications
> >3) support authentication
> >
> >And here it comes...
> >
> >Why not use a message bus (an AMQP implementation) for
> >communication between all involved components?
> >- it supports all required features out of the box
> >- clients exists for all languages involved in Aeolus project
> >- notifications will be solved in the same way between all components
> >
> >Or is there some other solution how to solve notifications as
> >painless as possible while keeping required robustness? What is
> >your preferred solution of this problem?
> A message bus can be used currently.  An ESB is a prime example of
> how you can take what we have now and deploy Aeolus with a messaging
> architecture.  In my opinion using a message bus should be a
> deployment decision.  Using ReST and callbacks in the way we do,
> keeps things flexible, simple, allows us to easily 'componentize'
> Aeolus as well as allowing users to configure a messaging
> architecture in a production environment using something like
> JBossESB or SwitchYard.
> 
> We could argue that we should provide a configure parameter that
> sets up an ESB and drops in queues/topics, but I think this is
> beyond the scope of the project (Maybe if some companies want to
> offer support for setting up production environments using
> messaging, they could offer this as part of a service ;) )
> 
> Another reason for sticking with ReST I think is the fact that we
> are so far down the line now, it would be quite an undertaking to
> add messaging in all the projects.
> 
> Alternatively, how about we write a library that handles ReST
> callbacks, this should keep it consistent, and we can reuse it
> across projects.  Maybe an extension to ActiveResource?
> 
> Cheers
> 
> Martyn

This is a pretty interesting idea and is something Jay G was looking at
quite a while back IIRC. We'd need to constrain it such that we don't
wind up writing yet-another-messaging-system, but I find the basic idea
pretty appealing.

--H

-- 
== Hugh Brock, hbrock at redhat.com                                   ==
== Engineering Manager, Cloud BU                                   ==
== Aeolus Project: Manage virtual infrastructure across clouds.    ==
== http://aeolusproject.org                                        ==

"I know that you believe you understand what you think I said, but I’m
not sure you realize that what you heard is not what I meant."
--Robert McCloskey


More information about the aeolus-devel mailing list