FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Infrastructure

 
 
LinkBack Thread Tools
 
Old 02-09-2010, 12:23 AM
Brennan Ashton
 
Default RFR for AMQP project

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
_______________________________________________
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
 
Old 02-09-2010, 04:54 PM
Jose Manimala
 
Default RFR for AMQP project

On 2/9/2010 6:53 AM, Brennan Ashton 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
> _______________________________________________
> infrastructure mailing list
> infrastructure@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/infrastructure
>
Hello brennan,
Is this similar to the Enterprise Services
Bus(tibco). I have experience working with it and can help with the same.

Best regards
Jose Mathew Manimala
_______________________________________________
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
 
Old 02-10-2010, 05:33 AM
Brennan Ashton
 
Default RFR for AMQP project

On Tue, Feb 9, 2010 at 12:54 PM, Jose Manimala <josemanimala@gmail.com> wrote:
> On 2/9/2010 6:53 AM, Brennan Ashton 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
>> _______________________________________________
>> infrastructure mailing list
>> infrastructure@lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/infrastructure
>>
> Hello brennan,
> * * * * * * * * * * * * Is this similar to the Enterprise Services
> Bus(tibco). I have experience working with it and can help with the same.
>
> Best regards
> Jose Mathew Manimala

AMQP is an open standard that is designed to fill what IBM and Tibco
are doing, but in an open way so that many different services can work
with it. For us we are using the qpid broker. It would be great to
have your insight and help as I am still a little hazy on how the
infrastructure is going to all tie together, especially in terms of
information security.

Thanks,
Brennan Ashton
_______________________________________________
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
 
Old 02-10-2010, 08:34 AM
jose manimala
 
Default RFR for AMQP project

Hello brennan,
information security was a major problem with tibco as well. What has
been done is to ensure that the services that need to run on the
broker implement ssl and then use the ssl wrapper that comes with the
broker. And when a client needs to use one of the broker exposed
services that would also be exposed over ssl. I don't know how much
this helps. The services are best hosted on a cluster of virtual
machines.
Jose

On 2/10/10, Brennan Ashton <bashton@brennanashton.com> wrote:
> On Tue, Feb 9, 2010 at 12:54 PM, Jose Manimala <josemanimala@gmail.com>
> wrote:
>> On 2/9/2010 6:53 AM, Brennan Ashton 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
>>> _______________________________________________
>>> infrastructure mailing list
>>> infrastructure@lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/infrastructure
>>>
>> Hello brennan,
>> * * * * * * * * * * * * Is this similar to the Enterprise Services
>> Bus(tibco). I have experience working with it and can help with the same.
>>
>> Best regards
>> Jose Mathew Manimala
>
> AMQP is an open standard that is designed to fill what IBM and Tibco
> are doing, but in an open way so that many different services can work
> with it. For us we are using the qpid broker. It would be great to
> have your insight and help as I am still a little hazy on how the
> infrastructure is going to all tie together, especially in terms of
> information security.
>
> Thanks,
> Brennan Ashton
> _______________________________________________
> infrastructure mailing list
> infrastructure@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/infrastructure
>


--
Jose M Manimala
http://www.jmmblog.in.eu.org
Ph: +919884065040
GPGkeyID: F5DD9656
_______________________________________________
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
 
Old 02-21-2010, 03:03 AM
Brennan Ashton
 
Default RFR for AMQP project

On Mon, Feb 8, 2010 at 8:23 PM, Brennan Ashton
<bashton@brennanashton.com> 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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
 
Old 02-21-2010, 03:10 AM
Jon Stanley
 
Default RFR for AMQP project

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@brennanashton.com> wrote:
> On Mon, Feb 8, 2010 at 8:23 PM, Brennan Ashton
> <bashton@brennanashton.com> 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@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/infrastructure
>

--
Sent from my mobile device
_______________________________________________
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
 
Old 02-21-2010, 11:28 PM
Brennan Ashton
 
Default RFR for AMQP project

On Sat, Feb 20, 2010 at 11:10 PM, Jon Stanley <jonstanley@gmail.com> wrote:
> 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@brennanashton.com> wrote:
>> On Mon, Feb 8, 2010 at 8:23 PM, Brennan Ashton
>> <bashton@brennanashton.com> 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@lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/infrastructure
>>
>
> --
> Sent from my mobile device
> _______________________________________________
> infrastructure mailing list
> infrastructure@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/infrastructure
>

publictest14 has been claimed for this project.

Thanks,
Brennan Ashton
_______________________________________________
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
 

Thread Tools




All times are GMT. The time now is 07:40 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org