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(a)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