Creation of a new SIG "Messaging" =================================
Hereby, I'm asking for comments about founding a new SIG to handle messaging stacks in CentOS. We currently have in CentOS RabbitMQ handling AMQP 0.9, and QPID, which provides messaging using AMQP 1.0. There are also packages supporting Kafka, but not Kafka itself.
Collaborating SIGs would be the Cloud and the Opstools SIGs. Both would be consuming built packages produced by the Messaging SIG.
We also briefly took into consideration to incorporate the newly proposed SIG into one of the others. At the end, messaging is different than Cloud or Operational tools. It doesn't really fit. The best solution seemed to us to have another SIG.
If there are any questions or comments, please don't hesitate to reply to the list, and let's find the best proposal here.
Matthias
On 02/07/18 13:36, Matthias Runge wrote:
Creation of a new SIG "Messaging"
Hereby, I'm asking for comments about founding a new SIG to handle messaging stacks in CentOS. We currently have in CentOS RabbitMQ handling AMQP 0.9, and QPID, which provides messaging using AMQP 1.0. There are also packages supporting Kafka, but not Kafka itself.
Collaborating SIGs would be the Cloud and the Opstools SIGs. Both would be consuming built packages produced by the Messaging SIG.
We also briefly took into consideration to incorporate the newly proposed SIG into one of the others. At the end, messaging is different than Cloud or Operational tools. It doesn't really fit. The best solution seemed to us to have another SIG.
If there are any questions or comments, please don't hesitate to reply to the list, and let's find the best proposal here.
Matthias
Both rabbitmq and qpid packages already exist in EPEL. RabbitMQ is on the latest 3.6.x version but that is dependent on the version of erlang that's available - and EPEL currently supplies R16B-03.18.el7. The 3.6 series is still current and supported AFAIK. Getting a more recent version would mean a rebase of erlang.
Don't know anything about qpid but the EPEL packages are currently 1.38.0-1.el7
Trevor
On Mon, Jul 02, 2018 at 03:33:06PM +0100, Trevor Hemsley via CentOS-devel wrote:
On 02/07/18 13:36, Matthias Runge wrote:
Creation of a new SIG "Messaging"
Hereby, I'm asking for comments about founding a new SIG to handle messaging stacks in CentOS. We currently have in CentOS RabbitMQ handling AMQP 0.9, and QPID, which provides messaging using AMQP 1.0. There are also packages supporting Kafka, but not Kafka itself.
Collaborating SIGs would be the Cloud and the Opstools SIGs. Both would be consuming built packages produced by the Messaging SIG.
We also briefly took into consideration to incorporate the newly proposed SIG into one of the others. At the end, messaging is different than Cloud or Operational tools. It doesn't really fit. The best solution seemed to us to have another SIG.
If there are any questions or comments, please don't hesitate to reply to the list, and let's find the best proposal here.
Matthias
Both rabbitmq and qpid packages already exist in EPEL. RabbitMQ is on the latest 3.6.x version but that is dependent on the version of erlang that's available - and EPEL currently supplies R16B-03.18.el7. The 3.6 series is still current and supported AFAIK. Getting a more recent version would mean a rebase of erlang.
Don't know anything about qpid but the EPEL packages are currently 1.38.0-1.el7
So, EPEL is not acceptable in Opstools nor in Cloud. If you want to link against libraries, you'll need to have them available directly in the build system, not via external repositories.
The other thing I really like with the idea of having a SIG is its clear (and small) focus. With that, you don't need to worry that some other package gets overwritten.
It's quite easy to get a package into EPEL. We all know, it happens from time to time, that packages there get upgraded at times you don't really like, especially when that breaks your CI.
Matthias
On 2 July 2018 at 11:14, Matthias Runge mrunge@matthias-runge.de wrote:
On Mon, Jul 02, 2018 at 03:33:06PM +0100, Trevor Hemsley via CentOS-devel wrote:
On 02/07/18 13:36, Matthias Runge wrote:
Creation of a new SIG "Messaging"
Hereby, I'm asking for comments about founding a new SIG to handle messaging stacks in CentOS. We currently have in CentOS RabbitMQ handling AMQP 0.9, and QPID, which provides messaging using AMQP 1.0. There are also packages supporting Kafka, but not Kafka itself.
Collaborating SIGs would be the Cloud and the Opstools SIGs. Both would be consuming built packages produced by the Messaging SIG.
We also briefly took into consideration to incorporate the newly proposed SIG into one of the others. At the end, messaging is different than Cloud or Operational tools. It doesn't really fit. The best solution seemed to us to have another SIG.
If there are any questions or comments, please don't hesitate to reply to the list, and let's find the best proposal here.
Matthias
Both rabbitmq and qpid packages already exist in EPEL. RabbitMQ is on the latest 3.6.x version but that is dependent on the version of erlang that's available - and EPEL currently supplies R16B-03.18.el7. The 3.6 series is still current and supported AFAIK. Getting a more recent version would mean a rebase of erlang.
Don't know anything about qpid but the EPEL packages are currently 1.38.0-1.el7
So, EPEL is not acceptable in Opstools nor in Cloud. If you want to link against libraries, you'll need to have them available directly in the build system, not via external repositories.
The other thing I really like with the idea of having a SIG is its clear (and small) focus. With that, you don't need to worry that some other package gets overwritten.
It's quite easy to get a package into EPEL. We all know, it happens from time to time, that packages there get upgraded at times you don't really like, especially when that breaks your CI.
So EPEL seems to have 2 different sets of problems occurring. We get told by SIG A that the version of package is too old for them and it needs to be updated. It then gets updated and it breaks SIG B. And shortly later something SIG-B needs is going to break SIG-A.
There is also the problem that the users can't mix and match Sig-A and Sig-B which was the original impetus several of those things being in EPEL. I am looking for ideas on how to better serve both problems but there is a point where it is each SIG needs to either work with each other or make sure that are clear what they can't mix with.
On Mon, Jul 2, 2018 at 9:14 AM, Matthias Runge mrunge@matthias-runge.de wrote:
It's quite easy to get a package into EPEL. We all know, it happens from time to time, that packages there get upgraded at times you don't really like, especially when that breaks your CI.
Have you tried epel-testing and reporting feedback in Bodhi?
The Bodhi process is more transparent than the CBS tag promotion process from -candidate to -testing to -release.
- Ken
On Mon, Jul 2, 2018 at 11:14 AM Matthias Runge mrunge@matthias-runge.de wrote:
On Mon, Jul 02, 2018 at 03:33:06PM +0100, Trevor Hemsley via CentOS-devel wrote:
On 02/07/18 13:36, Matthias Runge wrote:
Creation of a new SIG "Messaging"
Hereby, I'm asking for comments about founding a new SIG to handle messaging stacks in CentOS. We currently have in CentOS RabbitMQ handling AMQP 0.9, and QPID, which provides messaging using AMQP 1.0. There are also packages supporting Kafka, but not Kafka itself.
Collaborating SIGs would be the Cloud and the Opstools SIGs. Both would be consuming built packages produced by the Messaging SIG.
We also briefly took into consideration to incorporate the newly proposed SIG into one of the others. At the end, messaging is different than Cloud or Operational tools. It doesn't really fit. The best solution seemed to us to have another SIG.
If there are any questions or comments, please don't hesitate to reply to the list, and let's find the best proposal here.
Matthias
Both rabbitmq and qpid packages already exist in EPEL. RabbitMQ is on the latest 3.6.x version but that is dependent on the version of erlang that's available - and EPEL currently supplies R16B-03.18.el7. The 3.6 series is still current and supported AFAIK. Getting a more recent version would mean a rebase of erlang.
Don't know anything about qpid but the EPEL packages are currently 1.38.0-1.el7
So, EPEL is not acceptable in Opstools nor in Cloud. If you want to link against libraries, you'll need to have them available directly in the build system, not via external repositories.
The other thing I really like with the idea of having a SIG is its clear (and small) focus. With that, you don't need to worry that some other package gets overwritten.
It's quite easy to get a package into EPEL. We all know, it happens from time to time, that packages there get upgraded at times you don't really like, especially when that breaks your CI.
I don't want to sound too rude here, but have you tried actually being involved in the maintainership of those packages in EPEL that you need?
An explosion of SIGs also causes its own burdens, and things that are common to multiple SIGs probably should be in EPEL so that maintenance is shared and used by everyone.
On 2 July 2018 at 13:54, Neal Gompa ngompa13@gmail.com wrote:
On Mon, Jul 2, 2018 at 11:14 AM Matthias Runge mrunge@matthias-runge.de wrote:
On Mon, Jul 02, 2018 at 03:33:06PM +0100, Trevor Hemsley via CentOS-devel wrote:
On 02/07/18 13:36, Matthias Runge wrote:
Creation of a new SIG "Messaging"
Hereby, I'm asking for comments about founding a new SIG to handle messaging stacks in CentOS. We currently have in CentOS RabbitMQ handling AMQP 0.9, and QPID, which provides messaging using AMQP 1.0. There are also packages supporting Kafka, but not Kafka itself.
Collaborating SIGs would be the Cloud and the Opstools SIGs. Both would be consuming built packages produced by the Messaging SIG.
We also briefly took into consideration to incorporate the newly proposed SIG into one of the others. At the end, messaging is different than Cloud or Operational tools. It doesn't really fit. The best solution seemed to us to have another SIG.
If there are any questions or comments, please don't hesitate to reply to the list, and let's find the best proposal here.
Matthias
Both rabbitmq and qpid packages already exist in EPEL. RabbitMQ is on the latest 3.6.x version but that is dependent on the version of erlang that's available - and EPEL currently supplies R16B-03.18.el7. The 3.6 series is still current and supported AFAIK. Getting a more recent version would mean a rebase of erlang.
Don't know anything about qpid but the EPEL packages are currently 1.38.0-1.el7
So, EPEL is not acceptable in Opstools nor in Cloud. If you want to link against libraries, you'll need to have them available directly in the build system, not via external repositories.
The other thing I really like with the idea of having a SIG is its clear (and small) focus. With that, you don't need to worry that some other package gets overwritten.
It's quite easy to get a package into EPEL. We all know, it happens from time to time, that packages there get upgraded at times you don't really like, especially when that breaks your CI.
I don't want to sound too rude here, but have you tried actually being involved in the maintainership of those packages in EPEL that you need?
I believe Mathias has worked on various parts of EPEL and other repositories for a long time. His frustration with things changing out from underneath him in EPEL several times are quite valid. I don't think that there is going to be one answer to fixing this, but there may be methods that it can be done to make it less frustrating.
An explosion of SIGs also causes its own burdens, and things that are common to multiple SIGs probably should be in EPEL so that maintenance is shared and used by everyone.
-- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Mon, Jul 02, 2018 at 02:03:19PM -0400, Stephen John Smoogen wrote:
On 2 July 2018 at 13:54, Neal Gompa ngompa13@gmail.com wrote:
On Mon, Jul 2, 2018 at 11:14 AM Matthias Runge mrunge@matthias-runge.de wrote:
It's quite easy to get a package into EPEL. We all know, it happens from time to time, that packages there get upgraded at times you don't really like, especially when that breaks your CI.
I don't want to sound too rude here, but have you tried actually being involved in the maintainership of those packages in EPEL that you need?
I believe Mathias has worked on various parts of EPEL and other repositories for a long time. His frustration with things changing out from underneath him in EPEL several times are quite valid. I don't think that there is going to be one answer to fixing this, but there may be methods that it can be done to make it less frustrating.
An explosion of SIGs also causes its own burdens, and things that are common to multiple SIGs probably should be in EPEL so that maintenance is shared and used by everyone.
I'm in contact especially with the fine folks maintaining qpid and proton in EPEL. Having the SIG does not mean, the packages from EPEL need to go away. Since I need the packages being included in a buildroot on the centos build system, I believe, this discussion doesn't get us far.
Ideally, we'll catch regressions before packages are being pushed to any repository. I'd like a tighter integration in CI systems like with RDO CI.
Re: explosion of SIGs, I hope you mean the explosion of number of SIGs ;-)
We have currently the unfortunate situatuation with ansible, for example. It is used/built/consumed in multiple SIGs, and then cross-tagged to others. With Ansible, we don't have linking issues, when you're using multiple different versions of the same package.
In my opinion, Having a number of SIGs with a clear and defined focus will probably help us more than having a single repository with mixing all stuff together.
Matthias
On 02/07/18 13:36, Matthias Runge wrote:
Creation of a new SIG "Messaging"
Hereby, I'm asking for comments about founding a new SIG to handle messaging stacks in CentOS. We currently have in CentOS RabbitMQ handling AMQP 0.9, and QPID, which provides messaging using AMQP 1.0. There are also packages supporting Kafka, but not Kafka itself.
Collaborating SIGs would be the Cloud and the Opstools SIGs. Both would be consuming built packages produced by the Messaging SIG.
We also briefly took into consideration to incorporate the newly proposed SIG into one of the others. At the end, messaging is different than Cloud or Operational tools. It doesn't really fit. The best solution seemed to us to have another SIG.
If there are any questions or comments, please don't hesitate to reply to the list, and let's find the best proposal here.
Matthias
+1
On Tue, Jul 03, 2018 at 09:39:06AM +0100, Karanbir Singh wrote:
On 02/07/18 13:36, Matthias Runge wrote:
Creation of a new SIG "Messaging"
Hereby, I'm asking for comments about founding a new SIG to handle messaging stacks in CentOS. We currently have in CentOS RabbitMQ handling AMQP 0.9, and QPID, which provides messaging using AMQP 1.0. There are also packages supporting Kafka, but not Kafka itself.
Collaborating SIGs would be the Cloud and the Opstools SIGs. Both would be consuming built packages produced by the Messaging SIG.
We also briefly took into consideration to incorporate the newly proposed SIG into one of the others. At the end, messaging is different than Cloud or Operational tools. It doesn't really fit. The best solution seemed to us to have another SIG.
If there are any questions or comments, please don't hesitate to reply to the list, and let's find the best proposal here.
Matthias
+1
KB, would that you being the board member to join the effort here?
If yes, can we please proceed? The next step would be to request resources being created?[1]
Matthias
[1] https://wiki.centos.org/SIGGuide#head-3f04c5f9db77fc94d43994c805948e20344f69...
On Thu, Jul 12, 2018 at 09:25:04AM +0200, Matthias Runge wrote:
On Tue, Jul 03, 2018 at 09:39:06AM +0100, Karanbir Singh wrote:
On 02/07/18 13:36, Matthias Runge wrote:
Creation of a new SIG "Messaging"
Hereby, I'm asking for comments about founding a new SIG to handle messaging stacks in CentOS. We currently have in CentOS RabbitMQ handling AMQP 0.9, and QPID, which provides messaging using AMQP 1.0. There are also packages supporting Kafka, but not Kafka itself.
+1
KB, would that you being the board member to join the effort here?
If yes, can we please proceed? The next step would be to request resources being created?[1]
Matthias
[1] https://wiki.centos.org/SIGGuide#head-3f04c5f9db77fc94d43994c805948e20344f69...
ping?
Matthias
On Tue, Jul 24, 2018 at 11:23:38AM +0200, Matthias Runge wrote:
On Thu, Jul 12, 2018 at 09:25:04AM +0200, Matthias Runge wrote:
On Tue, Jul 03, 2018 at 09:39:06AM +0100, Karanbir Singh wrote:
On 02/07/18 13:36, Matthias Runge wrote:
Creation of a new SIG "Messaging"
Hereby, I'm asking for comments about founding a new SIG to handle messaging stacks in CentOS. We currently have in CentOS RabbitMQ handling AMQP 0.9, and QPID, which provides messaging using AMQP 1.0. There are also packages supporting Kafka, but not Kafka itself.
+1
KB, would that you being the board member to join the effort here?
If yes, can we please proceed? The next step would be to request resources being created?[1]
Matthias
[1] https://wiki.centos.org/SIGGuide#head-3f04c5f9db77fc94d43994c805948e20344f69...
ping?
Another ping here? What can I do to speed things up, or where would we need what to make it real?
Matthias
On 02 Jul 14:36, Matthias Runge wrote:
Creation of a new SIG "Messaging"
Hereby, I'm asking for comments about founding a new SIG to handle messaging stacks in CentOS. We currently have in CentOS RabbitMQ handling AMQP 0.9, and QPID, which provides messaging using AMQP 1.0. There are also packages supporting Kafka, but not Kafka itself.
+1.
Matthias, do you want to say anything in the August newsletter about this effort, or is that still premature?
On 07/02/2018 08:36 AM, Matthias Runge wrote:
Creation of a new SIG "Messaging"
Hereby, I'm asking for comments about founding a new SIG to handle messaging stacks in CentOS. We currently have in CentOS RabbitMQ handling AMQP 0.9, and QPID, which provides messaging using AMQP 1.0. There are also packages supporting Kafka, but not Kafka itself.
Collaborating SIGs would be the Cloud and the Opstools SIGs. Both would be consuming built packages produced by the Messaging SIG.
We also briefly took into consideration to incorporate the newly proposed SIG into one of the others. At the end, messaging is different than Cloud or Operational tools. It doesn't really fit. The best solution seemed to us to have another SIG.
If there are any questions or comments, please don't hesitate to reply to the list, and let's find the best proposal here.
Matthias
-
Julien Pivotto -
Karanbir Singh -
Ken Dreyer -
Matthias Runge -
Neal Gompa -
Rich Bowen -
Stephen John Smoogen -
Trevor Hemsley