Mon 23 Nov 2009
FUDCon, the AMQP story
Posted by J5 under AMQP , Standards , conference , messaging , tubesComments Off
With FUDCon being only two weeks away, I’ve been polishing up my presentation and looking into what is in store for the future of Fedora’s Infrastructure. My main focus has been adding “push” capabilities throughout our infrastructure via the use of the AMQP protocol and qpid servers.
So why do we care about push messaging?
One can think of messaging as a conversation between two people. Poll messaging goes something like this:
Push on the other hand is a bit less chatty:
By eliminating the need to poll to know when an event has happened within Fedora’s Infrastucture, and making it easy for services to push out events in an easy fire and forget manner, we open up the door to a number of interesting possibilities. For instance, instead of implementing mail notification functionality in every service we simply create a mail notification service that listens for events and sends e-mails to people who what them. Do you want to get a notification on your desktop when your build is done instead? This makes it possible to provide that functionality without bogging down the Koji build service.
Human consumable notifications isn’t the only advantage of adding push messaging to our infrastructure. Because the data is first formatted for services to consume, notifications can be used for things like automation and synchronization. For instance someone could write a script that listens for new git checkins at fedorahosted.org and tries to package it into a private repo for personal testing.
What do we need to discuss at FUDCon?
Though this change is minimally invasive and you can ignore it if you don’t need to work with notifications, it is never the less a large undertaking. Some of the things we need to discuss are:
- Usecases – where can we benefit by adding notifications? How do we envision the notifications will be consumed?
- Payload format – what are the pros and cons of the different ways we can encode and decode data
- Standardization – even though we have a routing protocol we still need to standardize on the type of data to expect
- Libraries – we need to make it dirt easy for infrastructure developers to add notifications to their service
- Performance and security concerns – AMQP is pretty complex so we will need to make sure all of our bases are covered when deploying the QPID servers
AMQP Sessions at FUDCon
There are a couple of talks planned and a hackfest. Come to the talks to get a deeper understanding of AMQP and how we envision using it within Fedora and then attend the hackfest to help us map out the future of the Fedora Messaging Infrastructure.
Saturday:
- AMQP Messaging for Fedora Developers – come to my session to find out the basics of AMQP messaging and how it is relevant to Fedora’s infrastructure
- AMQP/Qpid on Fedora – The definitive guide – get a more in-depth view of AMQP in Rajith Attapattu session. He will show you how to setup and configure the Qpid server on Fedora, use the client APIs, and where to go to find help when using AMQP.
Sunday and/or Monday:
- Get on the (Message) BUS Hackfest! – come to Jesse Keating’s hackfest to work out details and hack on the messaging infrastructure.

