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, [email protected] == == 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
