User:Bashton/AMQP RFR

From FedoraProject

< User:Bashton(Difference between revisions)
Jump to: navigation, search
(Created page with ' = Project Sponsor = <pre> Name: Brennan Ashton Fedora Account Name: bashton Group: Infrastructure Infrastructure Sponsor: </pre> == Secondary Contact info == <pre> Name: Jes...')
 
 
(3 intermediate revisions by one user not shown)
Line 1: Line 1:
 
 
= Project Sponsor =
 
= Project Sponsor =
<pre>
+
 
 
Name: Brennan Ashton
 
Name: Brennan Ashton
  
Line 8: Line 7:
 
Group: Infrastructure
 
Group: Infrastructure
  
Infrastructure Sponsor:
+
Infrastructure Sponsor: jkeating
</pre>
+
  
 
== Secondary Contact info ==
 
== Secondary Contact info ==
<pre>
 
 
Name: Jesse Keating
 
Name: Jesse Keating
  
Line 18: Line 15:
  
 
Group: Infrastructure
 
Group: Infrastructure
</pre>
 
  
 
== Project Info ==
 
== Project Info ==
<pre>
 
 
Project Name: Fedora Messaging Bus
 
Project Name: Fedora Messaging Bus
  
 
Target Audience: Infrastructure
 
Target Audience: Infrastructure
  
Expiration/Delivery Date (required):
+
Expiration/Delivery Date (required): Aug 1, 2010
  
 
Description/Summary:
 
Description/Summary:
Line 33: Line 28:
  
 
Project plan (Detailed):
 
Project plan (Detailed):
 +
 
The current target is somewhat outlined here:
 
The current target is somewhat outlined here:
 +
*https://fedoraproject.org/wiki/Messaging_SIG/PublishSubscribeNotificationProposal
 
*https://fedoraproject.org/wiki/Messaging_SIG
 
*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).
 
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).
  
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 as bugzilla, it will be very difficult to add dirrect support.
+
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.
 
+
The shims could be operating via email notifications (buzilla), or 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.
 
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.
Line 51: Line 44:
  
 
Goals:
 
Goals:
</pre>
+
*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 ==
 
== Specific resources needed ==
A test server is need to host:
+
*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.
*Broker(s)
+
*FAS
+
*Koji
+
*SCM
+
*procmail (recive bugzilla email from production server)
+
*various shims
+
  
  
 
[[Category:Infrastructure]]
 
[[Category:Infrastructure]]

Latest revision as of 22:33, 8 February 2010

Contents

[edit] Project Sponsor

Name: Brennan Ashton

Fedora Account Name: bashton

Group: Infrastructure

Infrastructure Sponsor: jkeating

[edit] Secondary Contact info

Name: Jesse Keating

Fedora Account Name: jkeating

Group: Infrastructure

[edit] 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:


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.

[edit] 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.