I'm out right now, but can you find some existing instance with available resources to meet your requirements? Feel free to put the stuff there. On 2/20/10, Brennan Ashton <bashton@xxxxxxxxxxxxxxxxx> wrote: > On Mon, Feb 8, 2010 at 8:23 PM, Brennan Ashton > <bashton@xxxxxxxxxxxxxxxxx> wrote: >> 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 >> > > What is the status of this being assigned to publictest? I would like > to move my work from my local virtual network to something public that > I can get collaboration on. > > Thanks, > Brennan > _______________________________________________ > infrastructure mailing list > infrastructure@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/infrastructure > -- Sent from my mobile device _______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/infrastructure