Notifications between Aeolus components

Martyn Taylor mtaylor at redhat.com
Wed Jan 9 10:53:58 UTC 2013


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
>
> Jan



More information about the aeolus-devel mailing list