RFR for AMQP project

Brennan Ashton bashton at brennanashton.com
Tue Feb 9 01:23:03 UTC 2010


Hey all,

I finally got around to putting the RFR for the AMPQ project.  I am
going to start working a lot more on this from now until completion,
so I would like to also get a feel for who else is wanting to help
with this project at this point.

== Project Sponsor ==
Name: Brennan Ashton  (IRC comphappy)
Fedora Account Name: bashton
Group: Infrastructure
Infrastructure Sponsor: jkeating

== Secondary Contact info ==
Name: Jesse Keating
Fedora Account Name: jkeating
Group: Infrastructure

== Project Info ==
Project Name: Fedora Messaging Bus
Target Audience: Infrastructure
Expiration/Delivery Date (required): Aug 1, 2010
Description/Summary:
Create a messaging bus for the various Fedora services to be able to
communicate with each other.

Project plan (Detailed):

The current target is somewhat outlined here:
*https://fedoraproject.org/wiki/Messaging_SIG/PublishSubscribeNotificationProposal
*https://fedoraproject.org/wiki/Messaging_SIG


We need to implement a test AMQP broker running qpid.  Depending on
how security domains are structured, this could be three or more
diffent brokers (Fedora Infrastructure, Fedora Community, FAS).

A library and API for the Fedora QMF interface will have to be defined
and written, this will be the interfaces that all fedora services
using the message bus will have to follow. The different fedora
services either need to have a shim implemented to take there current
interface and connect it to a broker, or be patched to allow for
dirrect message support. There will likely be a mix as some services
such like Bugzilla will be very difficult to add direct support
without forking from upstream. The shims could be operating via email
notifications (buzilla), xmlRPC, or a mix. The email based shims would
use procmail or simmilar to pass the information to an interperting
python script.

Once core services such as Koji, Pkgdb, SCM, FAS, and Buzilla have
functioning AMQP connections, and the broker is stable. This system
would then be pushed to production hardware.  Other services could
then be added in later.

Goals:
*Create a unified way of communicating between Fedora services.
*Allow for abstraction that would allow for easier migration of
services such as SCM.
*Allow for more real-time changes rather then depending on hourly cron jobs.
*More dynamic system.

== Specific resources needed ==
*A test server is need to host two or three guests, one to operate as
the broker, the other(s) to pass messages around and eventually run
services.


Thank you,
Brennan Ashton


More information about the infrastructure mailing list