Re: [openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack
Thomas, This may be of interest to you as well: http://specs.openstack.org/openstack/openstack-specs/specs/supported-messaging-drivers.html On Mon, Jun 22, 2015 at 12:57 PM, Davanum Srinivas wrote: > Thomas, > > here's a review for qpid > https://review.openstack.org/#/c/193804/ > > -- dims > > On Mon, Jun 22, 2015 at 12:42 PM, Thomas Goirand wrote: >> On 06/16/2015 03:22 PM, Sean Dague wrote: >>> FYI, >>> >>> One of the things that came out of the summit for Devstack plans going >>> forward is to trim it back to something more opinionated and remove a >>> bunch of low use optionality in the process. >>> >>> One of those branches to be trimmed is all the support for things beyond >>> RabbitMQ in the rpc layer. RabbitMQ is what's used by 95%+ of our >>> community, that's what the development environment should focus on. >>> >>> The patch to remove all of this is here - >>> https://review.openstack.org/#/c/192154/. Expect this to merge by the >>> end of the month. If people are interested in non RabbitMQ external >>> plugins, now is the time to start writing them. The oslo.messaging team >>> already moved their functional test installation for alternative >>> platforms off of devstack, so this should impact a very small number of >>> people. >>> >>> -Sean >> >> I agree with this, if and only if, we also remove Qpid and such from >> itoslo.messaging. It doesn't make sense if we only go half of the way, >> and only remove it from Devstack. >> >> Cheers, >> >> Thomas Goirand (zigo) >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > -- > Davanum Srinivas :: https://twitter.com/dims -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack
Thomas, here's a review for qpid https://review.openstack.org/#/c/193804/ -- dims On Mon, Jun 22, 2015 at 12:42 PM, Thomas Goirand wrote: > On 06/16/2015 03:22 PM, Sean Dague wrote: >> FYI, >> >> One of the things that came out of the summit for Devstack plans going >> forward is to trim it back to something more opinionated and remove a >> bunch of low use optionality in the process. >> >> One of those branches to be trimmed is all the support for things beyond >> RabbitMQ in the rpc layer. RabbitMQ is what's used by 95%+ of our >> community, that's what the development environment should focus on. >> >> The patch to remove all of this is here - >> https://review.openstack.org/#/c/192154/. Expect this to merge by the >> end of the month. If people are interested in non RabbitMQ external >> plugins, now is the time to start writing them. The oslo.messaging team >> already moved their functional test installation for alternative >> platforms off of devstack, so this should impact a very small number of >> people. >> >> -Sean > > I agree with this, if and only if, we also remove Qpid and such from > itoslo.messaging. It doesn't make sense if we only go half of the way, > and only remove it from Devstack. > > Cheers, > > Thomas Goirand (zigo) > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack
On 06/16/2015 03:22 PM, Sean Dague wrote: > FYI, > > One of the things that came out of the summit for Devstack plans going > forward is to trim it back to something more opinionated and remove a > bunch of low use optionality in the process. > > One of those branches to be trimmed is all the support for things beyond > RabbitMQ in the rpc layer. RabbitMQ is what's used by 95%+ of our > community, that's what the development environment should focus on. > > The patch to remove all of this is here - > https://review.openstack.org/#/c/192154/. Expect this to merge by the > end of the month. If people are interested in non RabbitMQ external > plugins, now is the time to start writing them. The oslo.messaging team > already moved their functional test installation for alternative > platforms off of devstack, so this should impact a very small number of > people. > > -Sean I agree with this, if and only if, we also remove Qpid and such from itoslo.messaging. It doesn't make sense if we only go half of the way, and only remove it from Devstack. Cheers, Thomas Goirand (zigo) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack
On 06/19/2015 03:16 PM, Ken Giusti wrote: > I've already +1'd this patch - timing issues aside - I think this is a > Good Thing from a developer's point of view. Particularly, my own > selfish point of view :) I envision the ability to support multiple > different messaging services via the amqp1 driver. Having to keep > devstack updated with an array of supported configurations is gonna be a > nightmare for all involved. I'd much rather have a small independent > plugin to work on rather than having to get every change included into > devstack proper. > > And thanks to Sean's excellent example I've started a plugin for the > amqp1.0 driver (totally untested at this point), so we'll have that > covered [0]. Thanks Sean! Neat! > That said, the only concern I have with this patch is whether it will > result in a less well-tested oslo.messaging. It shouldn't. One of the reasons the timing seemed appropriate here is that with the move by the O.M. to own their own setup for services in their functional tree, to the best of my knowledge there are no upstream test jobs using this code to gate project changes. Part of the reason for starting this email thread was to let any that were missed speak up so we could address it. You can use devstack plugins in gate jobs by simply adding 2 additional lines to your project test job definition. I've got a reorganized documentation patch to the devstack repo up for review that hopefully makes that even clearer - https://review.openstack.org/#/c/193519/2/doc/source/plugins.rst,cm (section starts at L199). This is the way that many official OpenStack projects, such as Trove, Zaqar, and Magnum test themselves today, and more and more things are moving to that model. It's really the only sustainable way to support a big OpenStack ecosystem. -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack
I've already +1'd this patch - timing issues aside - I think this is a Good Thing from a developer's point of view. Particularly, my own selfish point of view :) I envision the ability to support multiple different messaging services via the amqp1 driver. Having to keep devstack updated with an array of supported configurations is gonna be a nightmare for all involved. I'd much rather have a small independent plugin to work on rather than having to get every change included into devstack proper. And thanks to Sean's excellent example I've started a plugin for the amqp1.0 driver (totally untested at this point), so we'll have that covered [0]. Thanks Sean! That said, the only concern I have with this patch is whether it will result in a less well-tested oslo.messaging. O.M. is supposed to be an abstraction of the messaging bus - it's not just "RPC and Notifications over RabbitMQ", is it? How do we validate that abstraction if we don't thoroughly integration test O.M. over multiple different drivers/backends? Other folks have already raised the issue of rabbit-specific behaviors likely leaking through the API, especially with respect to failure scenarios. If we make it harder to run integration tests over anything but the rabbit driver, then we risk breaking that abstraction in such a way that using anything _other_ than rabbit will be practically impossible. [0] https://github.com/kgiusti/amqp1-devstack On Thu, Jun 18, 2015 at 12:28 PM Clint Byrum wrote: > Excerpts from Sean Dague's message of 2015-06-18 07:09:56 -0700: > > On 06/18/2015 09:54 AM, ozamiatin wrote: > > > Hi Sean, > > > > > > Thanks a lot for the plugin! > > > I was a little bit confused with a commit message and dropping of > > > drivers support. > > > It turns really not so hard to test zeromq driver with plugin. > > > > Yes, that was the design goal with the whole plugin mechanism. To > > provide an experience that was so minimally different from vanilla > > devstack, that most people would never even notice. It's honestly often > > easier to explain to people how to enable a service via a plugin than > > the config variables in tree. > > > > +1 > > > > So I have no objections any more and removing my -1. > > > > Cool, great. It would be great if you or someone else could post a > > review to pull this code into gerrit somewhere. You'll need the code in > > gerrit to use it in devstack-gate jobs, as we don't allow projects > > outside of gerrit to be cloned during tests. > > > > > But I also agree with Doug Hellmann and other speakers that we should > > > not make such changes > > > so fast. > > > > The reason I didn't think the time table was unreasonable was how quick > > this transition could be made, and how little code is needed to make one > > of these plugins. And the fact that from there on out you get to be in > > control of landing fixes or enhancements for your backend on the > > timetable that works for you. > > > > It will make getting the devstack-gate jobs working reliably a lot > > simpler and quicker for your team. > > > > Agreed on all points. I believe that the mistake was simply that > there wasn't any need to hold hands for those who we are enabling to > move faster and more independently. We do, in fact, need to transfer > ownership gracefully. Thanks so much for writing the plugin for zmq, > that is a huge win for zmq developers. I can't speak for oslo directly, > but it seems like that plugin should land under oslo's direct stewardship > and then we can move forward with this. > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack
Excerpts from Sean Dague's message of 2015-06-18 07:09:56 -0700: > On 06/18/2015 09:54 AM, ozamiatin wrote: > > Hi Sean, > > > > Thanks a lot for the plugin! > > I was a little bit confused with a commit message and dropping of > > drivers support. > > It turns really not so hard to test zeromq driver with plugin. > > Yes, that was the design goal with the whole plugin mechanism. To > provide an experience that was so minimally different from vanilla > devstack, that most people would never even notice. It's honestly often > easier to explain to people how to enable a service via a plugin than > the config variables in tree. > +1 > > So I have no objections any more and removing my -1. > > Cool, great. It would be great if you or someone else could post a > review to pull this code into gerrit somewhere. You'll need the code in > gerrit to use it in devstack-gate jobs, as we don't allow projects > outside of gerrit to be cloned during tests. > > > But I also agree with Doug Hellmann and other speakers that we should > > not make such changes > > so fast. > > The reason I didn't think the time table was unreasonable was how quick > this transition could be made, and how little code is needed to make one > of these plugins. And the fact that from there on out you get to be in > control of landing fixes or enhancements for your backend on the > timetable that works for you. > > It will make getting the devstack-gate jobs working reliably a lot > simpler and quicker for your team. > Agreed on all points. I believe that the mistake was simply that there wasn't any need to hold hands for those who we are enabling to move faster and more independently. We do, in fact, need to transfer ownership gracefully. Thanks so much for writing the plugin for zmq, that is a huge win for zmq developers. I can't speak for oslo directly, but it seems like that plugin should land under oslo's direct stewardship and then we can move forward with this. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack
On 06/18/2015 09:54 AM, ozamiatin wrote: > Hi Sean, > > Thanks a lot for the plugin! > I was a little bit confused with a commit message and dropping of > drivers support. > It turns really not so hard to test zeromq driver with plugin. Yes, that was the design goal with the whole plugin mechanism. To provide an experience that was so minimally different from vanilla devstack, that most people would never even notice. It's honestly often easier to explain to people how to enable a service via a plugin than the config variables in tree. > So I have no objections any more and removing my -1. Cool, great. It would be great if you or someone else could post a review to pull this code into gerrit somewhere. You'll need the code in gerrit to use it in devstack-gate jobs, as we don't allow projects outside of gerrit to be cloned during tests. > But I also agree with Doug Hellmann and other speakers that we should > not make such changes > so fast. The reason I didn't think the time table was unreasonable was how quick this transition could be made, and how little code is needed to make one of these plugins. And the fact that from there on out you get to be in control of landing fixes or enhancements for your backend on the timetable that works for you. It will make getting the devstack-gate jobs working reliably a lot simpler and quicker for your team. -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack
Hi Sean, Thanks a lot for the plugin! I was a little bit confused with a commit message and dropping of drivers support. It turns really not so hard to test zeromq driver with plugin. So I have no objections any more and removing my -1. But I also agree with Doug Hellmann and other speakers that we should not make such changes so fast. Thanks, Oleksii 6/18/15 16:36, Sean Dague пишет: On 06/18/2015 06:49 AM, Sean Dague wrote: On 06/18/2015 03:28 AM, ozamiatin wrote: Hi, please don't remove zmq support from devstack. We are now in progress of writing a new version of the driver. I use devstack each time to check the driver functionality. When the implementation become public it will be even more important to have a possibility to check it on devstack. Which will be extremely easy to continue doing with an external plugin, and also make it much simpler for you to add new enhancements to it. Your development workflow would be add the following line to your localrc: enable_plugin zmq git://.. And will continue exactly the same in usage pattern of devstack after that. So, instead of further explaining that this was going to be easy to do out of tree, I did it for the 0mq case. https://github.com/sdague/zmq-devstack is up and ready to go. It creates the same functional environment as the in code. You can demonstrate that by doing the following: git clone https://github.com/openstack-dev/devstack cd devstack git review -d 192154 (this is the code which deletes all the non rabbit code from the devstack tree) echo "enable_plugin zmq-devstack https://github.com/sdague/zmq-devstack"; localrc ./stack.sh Which I just did and tested in a local 14.04 vagrant (easily built with devstack-vagrant project). Looked through all the logs, things look like they are working to some degree. Saw a couple of stack traces that looked non fatal in nova-conductor, which would be the current state of the zmq driver from my understanding. I did not functionally test this beyond that, because from a devstack interface point of view, all the things devstack used to do (install redis, zmq code, start the oslo messaging zmq receiver, and setup all the config files for all the projects) match the output of the old code. The effort could use a README like the other devstack plugins have, to document to prospective users what variables they have access when using this. I'll leave that as an exercise for whenever someone imports this into gerrit to take ownership of it. Other drivers should be able to pretty closely model this in about 30 minutes of work. The install and post-config phases are probably the only ones you need. (install for installing code, post-config for starting servers). User friendly plugins will want to also want to implement clean and maybe unstack. (clean is implemented here, because it was in the old code). -Sean __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack
yay! thanks Sean. -- dims On Thu, Jun 18, 2015 at 9:36 AM, Sean Dague wrote: > On 06/18/2015 06:49 AM, Sean Dague wrote: >> On 06/18/2015 03:28 AM, ozamiatin wrote: >>> Hi, please don't remove zmq support from devstack. >>> We are now in progress of writing a new version of the driver. >>> I use devstack each time to check the driver functionality. >>> When the implementation become public it will be even more >>> important to have a possibility to check it on devstack. >> >> Which will be extremely easy to continue doing with an external plugin, >> and also make it much simpler for you to add new enhancements to it. >> Your development workflow would be add the following line to your localrc: >> >> enable_plugin zmq git://.. >> >> And will continue exactly the same in usage pattern of devstack after that. > > So, instead of further explaining that this was going to be easy to do > out of tree, I did it for the 0mq case. > > https://github.com/sdague/zmq-devstack is up and ready to go. It creates > the same functional environment as the in code. You can demonstrate that > by doing the following: > > git clone https://github.com/openstack-dev/devstack > cd devstack > git review -d 192154 (this is the code which deletes all the non rabbit > code from the devstack tree) > > echo "enable_plugin zmq-devstack https://github.com/sdague/zmq-devstack"; >>> localrc > ./stack.sh > > Which I just did and tested in a local 14.04 vagrant (easily built with > devstack-vagrant project). > > Looked through all the logs, things look like they are working to some > degree. Saw a couple of stack traces that looked non fatal in > nova-conductor, which would be the current state of the zmq driver from > my understanding. I did not functionally test this beyond that, because > from a devstack interface point of view, all the things devstack used to > do (install redis, zmq code, start the oslo messaging zmq receiver, and > setup all the config files for all the projects) match the output of the > old code. > > The effort could use a README like the other devstack plugins have, to > document to prospective users what variables they have access when using > this. I'll leave that as an exercise for whenever someone imports this > into gerrit to take ownership of it. > > Other drivers should be able to pretty closely model this in about 30 > minutes of work. The install and post-config phases are probably the > only ones you need. (install for installing code, post-config for > starting servers). User friendly plugins will want to also want to > implement clean and maybe unstack. (clean is implemented here, because > it was in the old code). > > -Sean > > -- > Sean Dague > http://dague.net > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack
On 06/18/2015 06:49 AM, Sean Dague wrote: > On 06/18/2015 03:28 AM, ozamiatin wrote: >> Hi, please don't remove zmq support from devstack. >> We are now in progress of writing a new version of the driver. >> I use devstack each time to check the driver functionality. >> When the implementation become public it will be even more >> important to have a possibility to check it on devstack. > > Which will be extremely easy to continue doing with an external plugin, > and also make it much simpler for you to add new enhancements to it. > Your development workflow would be add the following line to your localrc: > > enable_plugin zmq git://.. > > And will continue exactly the same in usage pattern of devstack after that. So, instead of further explaining that this was going to be easy to do out of tree, I did it for the 0mq case. https://github.com/sdague/zmq-devstack is up and ready to go. It creates the same functional environment as the in code. You can demonstrate that by doing the following: git clone https://github.com/openstack-dev/devstack cd devstack git review -d 192154 (this is the code which deletes all the non rabbit code from the devstack tree) echo "enable_plugin zmq-devstack https://github.com/sdague/zmq-devstack"; >> localrc ./stack.sh Which I just did and tested in a local 14.04 vagrant (easily built with devstack-vagrant project). Looked through all the logs, things look like they are working to some degree. Saw a couple of stack traces that looked non fatal in nova-conductor, which would be the current state of the zmq driver from my understanding. I did not functionally test this beyond that, because from a devstack interface point of view, all the things devstack used to do (install redis, zmq code, start the oslo messaging zmq receiver, and setup all the config files for all the projects) match the output of the old code. The effort could use a README like the other devstack plugins have, to document to prospective users what variables they have access when using this. I'll leave that as an exercise for whenever someone imports this into gerrit to take ownership of it. Other drivers should be able to pretty closely model this in about 30 minutes of work. The install and post-config phases are probably the only ones you need. (install for installing code, post-config for starting servers). User friendly plugins will want to also want to implement clean and maybe unstack. (clean is implemented here, because it was in the old code). -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack
On 06/18/2015 03:28 AM, ozamiatin wrote: > Hi, please don't remove zmq support from devstack. > We are now in progress of writing a new version of the driver. > I use devstack each time to check the driver functionality. > When the implementation become public it will be even more > important to have a possibility to check it on devstack. Which will be extremely easy to continue doing with an external plugin, and also make it much simpler for you to add new enhancements to it. Your development workflow would be add the following line to your localrc: enable_plugin zmq git://.. And will continue exactly the same in usage pattern of devstack after that. -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack
On 17/06/15 15:08 -0400, Doug Hellmann wrote: Excerpts from Sean Dague's message of 2015-06-17 14:07:35 -0400: On 06/17/2015 01:29 PM, Clint Byrum wrote: > Excerpts from Sean Dague's message of 2015-06-16 10:16:34 -0700: >> On 06/16/2015 12:49 PM, Clint Byrum wrote: >>> Excerpts from Sean Dague's message of 2015-06-16 06:22:23 -0700: FYI, One of the things that came out of the summit for Devstack plans going forward is to trim it back to something more opinionated and remove a bunch of low use optionality in the process. One of those branches to be trimmed is all the support for things beyond RabbitMQ in the rpc layer. RabbitMQ is what's used by 95%+ of our community, that's what the development environment should focus on. The patch to remove all of this is here - https://review.openstack.org/#/c/192154/. Expect this to merge by the end of the month. If people are interested in non RabbitMQ external plugins, now is the time to start writing them. The oslo.messaging team already moved their functional test installation for alternative platforms off of devstack, so this should impact a very small number of people. >>> >>> The recent spec we added to define a policy for oslo.messaging drivers is >>> intended as a way to encourage that 5% who feels a different messaging >>> layer is critical to participate upstream by adding devstack-gate jobs >>> and committing developers to keep them stable. This change basically >>> slams the door in their face and says "good luck, we don't actually care >>> about accomodating you." This will drive them more into the shadows, >>> and push their forks even further away from the core of the project. If >>> that's your intention, then we need to have a longer conversation where >>> you explain to me why you feel that's a good thing. >> >> I believe it is not the responsibility of the devstack team to support >> every possible backend one could imagine and carry that technical debt >> in tree, confusing new users in the process that any of these things >> might actually work. I believe that if you feel that your spec assumed >> that was going to be the case, you made a large incorrect externalities >> assumption. >> > > I agree with you, and support your desire to move things into plugins. > > However, your timing is problematic and the lack of coordination with > the ongoing effort to deprecate untested messaging drivers gracefully > is really frustrating. We've been asking (on this list) zmq interested > parties to add devstack-gate jobs and identify themselves as contacts > to support these drivers. Meanwhile this change and the wording around > it suggest that they're not welcome in devstack. So there has clearly been some disconnect here. This patch was originally going to come later in the cycle, but some back and forth on proton fixes with Flavio made me realize we really needed to get this direction out in front of more people (which is why it wasn't just a patch, it was also an email heads up). So there wasn't surprise when it was merged. We built the external plugin mechanism in devstack to make it very easy to extend out of tree, and make it easy to let people consume your out of tree stuff. It's the only way that devstack works in the big tent world, because there just is too much stuff for the team to support. Every change like this makes it harder for newcomers to participate. Frankly, it makes it harder for everyone because it means there are more moving parts, but in this specific case many of the people involved in these messaging drivers are relatively new, so I point that out. The already difficult task of setting up sufficient functional tests has now turned into "figure out devstack", too. The long-term Oslo team members can't do all of this work, any more than the devstack team can, but things were at least working in what we thought was a stable way so we could try to provide guidance. This is definitely an unfortunate side-effect of this change and it'll increase the burden we, oslo.messaging maintainers, will have to carry. Oslo messaging have moved away from using devstack for the functional tests, it doesn't even use plugins. However, this won't be enough to provide proper testing, as we're also requesting o.m drivers maintainers to have and integrated gate running (which will obviously require having a devstack plugin for o.m). In the long run, I think the split would benefit oslo.messaging as it'll give us more control on what's going on in devstack land for each driver. I'm personally tired of having patches like this[0] blocked because devstack is missing some packages. [0] https://review.openstack.org/#/c/192417/ I know none of us is arguing against the goal but the method. I just wanted to point something in favor of the change and also say that I agree we should have a proper deprecation path (keep reading). >>> Also, I take issue with the v
Re: [openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack
Hi, please don't remove zmq support from devstack. We are now in progress of writing a new version of the driver. I use devstack each time to check the driver functionality. When the implementation become public it will be even more important to have a possibility to check it on devstack. Thanks, Oleksii 6/17/15 20:29, Clint Byrum пишет: Excerpts from Sean Dague's message of 2015-06-16 10:16:34 -0700: On 06/16/2015 12:49 PM, Clint Byrum wrote: Excerpts from Sean Dague's message of 2015-06-16 06:22:23 -0700: FYI, One of the things that came out of the summit for Devstack plans going forward is to trim it back to something more opinionated and remove a bunch of low use optionality in the process. One of those branches to be trimmed is all the support for things beyond RabbitMQ in the rpc layer. RabbitMQ is what's used by 95%+ of our community, that's what the development environment should focus on. The patch to remove all of this is here - https://review.openstack.org/#/c/192154/. Expect this to merge by the end of the month. If people are interested in non RabbitMQ external plugins, now is the time to start writing them. The oslo.messaging team already moved their functional test installation for alternative platforms off of devstack, so this should impact a very small number of people. The recent spec we added to define a policy for oslo.messaging drivers is intended as a way to encourage that 5% who feels a different messaging layer is critical to participate upstream by adding devstack-gate jobs and committing developers to keep them stable. This change basically slams the door in their face and says "good luck, we don't actually care about accomodating you." This will drive them more into the shadows, and push their forks even further away from the core of the project. If that's your intention, then we need to have a longer conversation where you explain to me why you feel that's a good thing. I believe it is not the responsibility of the devstack team to support every possible backend one could imagine and carry that technical debt in tree, confusing new users in the process that any of these things might actually work. I believe that if you feel that your spec assumed that was going to be the case, you made a large incorrect externalities assumption. I agree with you, and support your desire to move things into plugins. However, your timing is problematic and the lack of coordination with the ongoing effort to deprecate untested messaging drivers gracefully is really frustrating. We've been asking (on this list) zmq interested parties to add devstack-gate jobs and identify themselves as contacts to support these drivers. Meanwhile this change and the wording around it suggest that they're not welcome in devstack. Also, I take issue with the value assigned to dropping it. If that 95% is calculated as orgs_running_on_rabbit/orgs then it's telling a really lop-sided story. I'd rather see compute_nodes_on_rabbit/compute_nodes. I'd like to propose that we leave all of this in tree to match what is in oslo.messaging. I think devstack should follow oslo.messaging and deprecate the ones that oslo.messaging deprecates. Otherwise I feel like we're Vizzini cutting the rope just as The Dread Pirate 0mq is about to climb the last 10 meters to the top of the cliffs of insanity and battle RabbitMQ left handed. I know, "inconceivable" right? We have an external plugin mechanism for devstack. That's a viable option here. People will have to own and do that work, instead of expecting the small devstack team to do that for them. I believe I left enough of a hook in place that it's possible. So lets do some communication, and ask for the qpid and zmq people to step up, and help them move their code into an external plugin, and add documentation to help their users find it. The burden should shift, but it still rests with devstack until it _does_ shift. That would also let them control the code relevant to their plugin, because there is no way that devstack was going to gate against other backends here, so we'd end up breaking them pretty often, and it taking a while to fix them in tree. I love that idea. That is not what the change does though. It deletes with nary a word about what users of this code should do until new external plugins appear. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack
Excerpts from Kyle Mestery's message of 2015-06-17 13:54:06 -0700: > On Wed, Jun 17, 2015 at 3:48 PM, Doug Hellmann > wrote: > > > Excerpts from Dan Smith's message of 2015-06-17 13:16:46 -0700: > > > > Every change like this makes it harder for newcomers to participate. > > > > Frankly, it makes it harder for everyone because it means there are > > > > more moving parts, but in this specific case many of the people > > > > involved in these messaging drivers are relatively new, so I point > > > > that out. > > > > > > I dunno about this. Having devstack migrate away from being an > > > opinionated tool for getting a test environment up that was eminently > > > readable to what it is today hasn't really helped anyone, IMHO. Having > > > some clear plug points such that we _can_ plug in the bits we need for > > > testing without having every possible option be embedded in the core > > > seems like goodness to me. I'd like to get back to the days where people > > > actually knew what was going on in devstack. That helps participation > > too. > > > > > > I think having devstack deploy what the 90% (or, being honest, 99%) are > > > running, with the ability to plug in the 1% bits when necessary is much > > > more in line with what the goal of the tool is. > > > > > > > The already difficult task of setting up sufficient > > > > functional tests has now turned into "figure out devstack", too. > > > > > > Yep, my point exactly. I think having clear points where you can setup > > > your thing and get it plugged in is much easier. > > > > I'm not questioning the goal, or even the approach. But we spent > > the last cycle building up the teams working on these drivers in > > Oslo, and at the summit several groups were (re)motivated to be > > working on the code. Now the devstack team is yanking the rug out > > from under all of that work with this patch. > > > > I'm asking that we not set a tight deadline on doing this right > > away, to give everyone who wasn't involved in those discussions > > about the changes in devstack to understand what's actually involved > > in recovering from being kicked out of tree. > > > > > I think people are overreacting here. Adding pluggable devstack support is > actually quite easy, and will honestly make the life of these new messaging > developers much easier. It's worth the time to go down this path from the > start for both sides. I don't see it as kicking them out, but enabling them. > Kyle, the point is that the relationship is delicate, and this patch _IS_ deleting the code that those contributors would use to interface with our testing system. The reaction isn't to how hard this is or whether or not it is a good idea. It is a reaction to the heavy handed approach which gives no consideration to the amount of time it will take for those contributors to establish their own external plugin on top of the already extremely daunting task of setting up gate/check jobs. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack
On Wed, Jun 17, 2015 at 3:48 PM, Doug Hellmann wrote: > Excerpts from Dan Smith's message of 2015-06-17 13:16:46 -0700: > > > Every change like this makes it harder for newcomers to participate. > > > Frankly, it makes it harder for everyone because it means there are > > > more moving parts, but in this specific case many of the people > > > involved in these messaging drivers are relatively new, so I point > > > that out. > > > > I dunno about this. Having devstack migrate away from being an > > opinionated tool for getting a test environment up that was eminently > > readable to what it is today hasn't really helped anyone, IMHO. Having > > some clear plug points such that we _can_ plug in the bits we need for > > testing without having every possible option be embedded in the core > > seems like goodness to me. I'd like to get back to the days where people > > actually knew what was going on in devstack. That helps participation > too. > > > > I think having devstack deploy what the 90% (or, being honest, 99%) are > > running, with the ability to plug in the 1% bits when necessary is much > > more in line with what the goal of the tool is. > > > > > The already difficult task of setting up sufficient > > > functional tests has now turned into "figure out devstack", too. > > > > Yep, my point exactly. I think having clear points where you can setup > > your thing and get it plugged in is much easier. > > I'm not questioning the goal, or even the approach. But we spent > the last cycle building up the teams working on these drivers in > Oslo, and at the summit several groups were (re)motivated to be > working on the code. Now the devstack team is yanking the rug out > from under all of that work with this patch. > > I'm asking that we not set a tight deadline on doing this right > away, to give everyone who wasn't involved in those discussions > about the changes in devstack to understand what's actually involved > in recovering from being kicked out of tree. > > I think people are overreacting here. Adding pluggable devstack support is actually quite easy, and will honestly make the life of these new messaging developers much easier. It's worth the time to go down this path from the start for both sides. I don't see it as kicking them out, but enabling them. Thanks, Kyle > Doug > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack
Excerpts from Dan Smith's message of 2015-06-17 13:16:46 -0700: > > Every change like this makes it harder for newcomers to participate. > > Frankly, it makes it harder for everyone because it means there are > > more moving parts, but in this specific case many of the people > > involved in these messaging drivers are relatively new, so I point > > that out. > > I dunno about this. Having devstack migrate away from being an > opinionated tool for getting a test environment up that was eminently > readable to what it is today hasn't really helped anyone, IMHO. Having > some clear plug points such that we _can_ plug in the bits we need for > testing without having every possible option be embedded in the core > seems like goodness to me. I'd like to get back to the days where people > actually knew what was going on in devstack. That helps participation too. > > I think having devstack deploy what the 90% (or, being honest, 99%) are > running, with the ability to plug in the 1% bits when necessary is much > more in line with what the goal of the tool is. > > > The already difficult task of setting up sufficient > > functional tests has now turned into "figure out devstack", too. > > Yep, my point exactly. I think having clear points where you can setup > your thing and get it plugged in is much easier. I'm not questioning the goal, or even the approach. But we spent the last cycle building up the teams working on these drivers in Oslo, and at the summit several groups were (re)motivated to be working on the code. Now the devstack team is yanking the rug out from under all of that work with this patch. I'm asking that we not set a tight deadline on doing this right away, to give everyone who wasn't involved in those discussions about the changes in devstack to understand what's actually involved in recovering from being kicked out of tree. Doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack
> Every change like this makes it harder for newcomers to participate. > Frankly, it makes it harder for everyone because it means there are > more moving parts, but in this specific case many of the people > involved in these messaging drivers are relatively new, so I point > that out. I dunno about this. Having devstack migrate away from being an opinionated tool for getting a test environment up that was eminently readable to what it is today hasn't really helped anyone, IMHO. Having some clear plug points such that we _can_ plug in the bits we need for testing without having every possible option be embedded in the core seems like goodness to me. I'd like to get back to the days where people actually knew what was going on in devstack. That helps participation too. I think having devstack deploy what the 90% (or, being honest, 99%) are running, with the ability to plug in the 1% bits when necessary is much more in line with what the goal of the tool is. > The already difficult task of setting up sufficient > functional tests has now turned into "figure out devstack", too. Yep, my point exactly. I think having clear points where you can setup your thing and get it plugged in is much easier. --Dan __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack
On Wed, Jun 17, 2015 at 2:44 PM, Sean Dague wrote: > On 06/17/2015 03:08 PM, Doug Hellmann wrote: > > Excerpts from Sean Dague's message of 2015-06-17 14:07:35 -0400: > >> On 06/17/2015 01:29 PM, Clint Byrum wrote: > >>> Excerpts from Sean Dague's message of 2015-06-16 10:16:34 -0700: > On 06/16/2015 12:49 PM, Clint Byrum wrote: > > Excerpts from Sean Dague's message of 2015-06-16 06:22:23 -0700: > >> FYI, > >> > >> One of the things that came out of the summit for Devstack plans > going > >> forward is to trim it back to something more opinionated and remove > a > >> bunch of low use optionality in the process. > >> > >> One of those branches to be trimmed is all the support for things > beyond > >> RabbitMQ in the rpc layer. RabbitMQ is what's used by 95%+ of our > >> community, that's what the development environment should focus on. > >> > >> The patch to remove all of this is here - > >> https://review.openstack.org/#/c/192154/. Expect this to merge by > the > >> end of the month. If people are interested in non RabbitMQ external > >> plugins, now is the time to start writing them. The oslo.messaging > team > >> already moved their functional test installation for alternative > >> platforms off of devstack, so this should impact a very small > number of > >> people. > >> > > > > The recent spec we added to define a policy for oslo.messaging > drivers is > > intended as a way to encourage that 5% who feels a different > messaging > > layer is critical to participate upstream by adding devstack-gate > jobs > > and committing developers to keep them stable. This change basically > > slams the door in their face and says "good luck, we don't actually > care > > about accomodating you." This will drive them more into the shadows, > > and push their forks even further away from the core of the project. > If > > that's your intention, then we need to have a longer conversation > where > > you explain to me why you feel that's a good thing. > > I believe it is not the responsibility of the devstack team to support > every possible backend one could imagine and carry that technical debt > in tree, confusing new users in the process that any of these things > might actually work. I believe that if you feel that your spec assumed > that was going to be the case, you made a large incorrect > externalities > assumption. > > >>> > >>> I agree with you, and support your desire to move things into plugins. > >>> > >>> However, your timing is problematic and the lack of coordination with > >>> the ongoing effort to deprecate untested messaging drivers gracefully > >>> is really frustrating. We've been asking (on this list) zmq interested > >>> parties to add devstack-gate jobs and identify themselves as contacts > >>> to support these drivers. Meanwhile this change and the wording around > >>> it suggest that they're not welcome in devstack. > >> > >> So there has clearly been some disconnect here. This patch was > >> originally going to come later in the cycle, but some back and forth on > >> proton fixes with Flavio made me realize we really needed to get this > >> direction out in front of more people (which is why it wasn't just a > >> patch, it was also an email heads up). So there wasn't surprise when it > >> was merged. > >> > >> We built the external plugin mechanism in devstack to make it very easy > >> to extend out of tree, and make it easy to let people consume your out > >> of tree stuff. It's the only way that devstack works in the big tent > >> world, because there just is too much stuff for the team to support. > > > > Every change like this makes it harder for newcomers to participate. > > Frankly, it makes it harder for everyone because it means there are > > more moving parts, but in this specific case many of the people > > involved in these messaging drivers are relatively new, so I point > > that out. The already difficult task of setting up sufficient > > functional tests has now turned into "figure out devstack", too. > > The long-term Oslo team members can't do all of this work, any more > > than the devstack team can, but things were at least working in > > what we thought was a stable way so we could try to provide guidance. > > > >> > > Also, I take issue with the value assigned to dropping it. If that > 95% > > is calculated as orgs_running_on_rabbit/orgs then it's telling a > really > > lop-sided story. I'd rather see > compute_nodes_on_rabbit/compute_nodes. > > > > I'd like to propose that we leave all of this in tree to match what > is > > in oslo.messaging. I think devstack should follow oslo.messaging and > > deprecate the ones that oslo.messaging deprecates. Otherwise I feel > like > > we're Vizzini cutting the rope just as The Dread Pirate 0mq is about > to > > climb the last 10 meters t
Re: [openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack
On 06/17/2015 03:08 PM, Doug Hellmann wrote: > Excerpts from Sean Dague's message of 2015-06-17 14:07:35 -0400: >> On 06/17/2015 01:29 PM, Clint Byrum wrote: >>> Excerpts from Sean Dague's message of 2015-06-16 10:16:34 -0700: On 06/16/2015 12:49 PM, Clint Byrum wrote: > Excerpts from Sean Dague's message of 2015-06-16 06:22:23 -0700: >> FYI, >> >> One of the things that came out of the summit for Devstack plans going >> forward is to trim it back to something more opinionated and remove a >> bunch of low use optionality in the process. >> >> One of those branches to be trimmed is all the support for things beyond >> RabbitMQ in the rpc layer. RabbitMQ is what's used by 95%+ of our >> community, that's what the development environment should focus on. >> >> The patch to remove all of this is here - >> https://review.openstack.org/#/c/192154/. Expect this to merge by the >> end of the month. If people are interested in non RabbitMQ external >> plugins, now is the time to start writing them. The oslo.messaging team >> already moved their functional test installation for alternative >> platforms off of devstack, so this should impact a very small number of >> people. >> > > The recent spec we added to define a policy for oslo.messaging drivers is > intended as a way to encourage that 5% who feels a different messaging > layer is critical to participate upstream by adding devstack-gate jobs > and committing developers to keep them stable. This change basically > slams the door in their face and says "good luck, we don't actually care > about accomodating you." This will drive them more into the shadows, > and push their forks even further away from the core of the project. If > that's your intention, then we need to have a longer conversation where > you explain to me why you feel that's a good thing. I believe it is not the responsibility of the devstack team to support every possible backend one could imagine and carry that technical debt in tree, confusing new users in the process that any of these things might actually work. I believe that if you feel that your spec assumed that was going to be the case, you made a large incorrect externalities assumption. >>> >>> I agree with you, and support your desire to move things into plugins. >>> >>> However, your timing is problematic and the lack of coordination with >>> the ongoing effort to deprecate untested messaging drivers gracefully >>> is really frustrating. We've been asking (on this list) zmq interested >>> parties to add devstack-gate jobs and identify themselves as contacts >>> to support these drivers. Meanwhile this change and the wording around >>> it suggest that they're not welcome in devstack. >> >> So there has clearly been some disconnect here. This patch was >> originally going to come later in the cycle, but some back and forth on >> proton fixes with Flavio made me realize we really needed to get this >> direction out in front of more people (which is why it wasn't just a >> patch, it was also an email heads up). So there wasn't surprise when it >> was merged. >> >> We built the external plugin mechanism in devstack to make it very easy >> to extend out of tree, and make it easy to let people consume your out >> of tree stuff. It's the only way that devstack works in the big tent >> world, because there just is too much stuff for the team to support. > > Every change like this makes it harder for newcomers to participate. > Frankly, it makes it harder for everyone because it means there are > more moving parts, but in this specific case many of the people > involved in these messaging drivers are relatively new, so I point > that out. The already difficult task of setting up sufficient > functional tests has now turned into "figure out devstack", too. > The long-term Oslo team members can't do all of this work, any more > than the devstack team can, but things were at least working in > what we thought was a stable way so we could try to provide guidance. > >> > Also, I take issue with the value assigned to dropping it. If that 95% > is calculated as orgs_running_on_rabbit/orgs then it's telling a really > lop-sided story. I'd rather see compute_nodes_on_rabbit/compute_nodes. > > I'd like to propose that we leave all of this in tree to match what is > in oslo.messaging. I think devstack should follow oslo.messaging and > deprecate the ones that oslo.messaging deprecates. Otherwise I feel like > we're Vizzini cutting the rope just as The Dread Pirate 0mq is about to > climb the last 10 meters to the top of the cliffs of insanity and battle > RabbitMQ left handed. I know, "inconceivable" right? We have an external plugin mechanism for devstack. That's a viable option here. People will have to own and do that work, instead of >>>
Re: [openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack
Excerpts from Sean Dague's message of 2015-06-17 14:07:35 -0400: > On 06/17/2015 01:29 PM, Clint Byrum wrote: > > Excerpts from Sean Dague's message of 2015-06-16 10:16:34 -0700: > >> On 06/16/2015 12:49 PM, Clint Byrum wrote: > >>> Excerpts from Sean Dague's message of 2015-06-16 06:22:23 -0700: > FYI, > > One of the things that came out of the summit for Devstack plans going > forward is to trim it back to something more opinionated and remove a > bunch of low use optionality in the process. > > One of those branches to be trimmed is all the support for things beyond > RabbitMQ in the rpc layer. RabbitMQ is what's used by 95%+ of our > community, that's what the development environment should focus on. > > The patch to remove all of this is here - > https://review.openstack.org/#/c/192154/. Expect this to merge by the > end of the month. If people are interested in non RabbitMQ external > plugins, now is the time to start writing them. The oslo.messaging team > already moved their functional test installation for alternative > platforms off of devstack, so this should impact a very small number of > people. > > >>> > >>> The recent spec we added to define a policy for oslo.messaging drivers is > >>> intended as a way to encourage that 5% who feels a different messaging > >>> layer is critical to participate upstream by adding devstack-gate jobs > >>> and committing developers to keep them stable. This change basically > >>> slams the door in their face and says "good luck, we don't actually care > >>> about accomodating you." This will drive them more into the shadows, > >>> and push their forks even further away from the core of the project. If > >>> that's your intention, then we need to have a longer conversation where > >>> you explain to me why you feel that's a good thing. > >> > >> I believe it is not the responsibility of the devstack team to support > >> every possible backend one could imagine and carry that technical debt > >> in tree, confusing new users in the process that any of these things > >> might actually work. I believe that if you feel that your spec assumed > >> that was going to be the case, you made a large incorrect externalities > >> assumption. > >> > > > > I agree with you, and support your desire to move things into plugins. > > > > However, your timing is problematic and the lack of coordination with > > the ongoing effort to deprecate untested messaging drivers gracefully > > is really frustrating. We've been asking (on this list) zmq interested > > parties to add devstack-gate jobs and identify themselves as contacts > > to support these drivers. Meanwhile this change and the wording around > > it suggest that they're not welcome in devstack. > > So there has clearly been some disconnect here. This patch was > originally going to come later in the cycle, but some back and forth on > proton fixes with Flavio made me realize we really needed to get this > direction out in front of more people (which is why it wasn't just a > patch, it was also an email heads up). So there wasn't surprise when it > was merged. > > We built the external plugin mechanism in devstack to make it very easy > to extend out of tree, and make it easy to let people consume your out > of tree stuff. It's the only way that devstack works in the big tent > world, because there just is too much stuff for the team to support. Every change like this makes it harder for newcomers to participate. Frankly, it makes it harder for everyone because it means there are more moving parts, but in this specific case many of the people involved in these messaging drivers are relatively new, so I point that out. The already difficult task of setting up sufficient functional tests has now turned into "figure out devstack", too. The long-term Oslo team members can't do all of this work, any more than the devstack team can, but things were at least working in what we thought was a stable way so we could try to provide guidance. > > >>> Also, I take issue with the value assigned to dropping it. If that 95% > >>> is calculated as orgs_running_on_rabbit/orgs then it's telling a really > >>> lop-sided story. I'd rather see compute_nodes_on_rabbit/compute_nodes. > >>> > >>> I'd like to propose that we leave all of this in tree to match what is > >>> in oslo.messaging. I think devstack should follow oslo.messaging and > >>> deprecate the ones that oslo.messaging deprecates. Otherwise I feel like > >>> we're Vizzini cutting the rope just as The Dread Pirate 0mq is about to > >>> climb the last 10 meters to the top of the cliffs of insanity and battle > >>> RabbitMQ left handed. I know, "inconceivable" right? > >> > >> We have an external plugin mechanism for devstack. That's a viable > >> option here. People will have to own and do that work, instead of > >> expecting the small devstack team to do that for them. I believe I left > >>
Re: [openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack
On 06/17/2015 01:29 PM, Clint Byrum wrote: > Excerpts from Sean Dague's message of 2015-06-16 10:16:34 -0700: >> On 06/16/2015 12:49 PM, Clint Byrum wrote: >>> Excerpts from Sean Dague's message of 2015-06-16 06:22:23 -0700: FYI, One of the things that came out of the summit for Devstack plans going forward is to trim it back to something more opinionated and remove a bunch of low use optionality in the process. One of those branches to be trimmed is all the support for things beyond RabbitMQ in the rpc layer. RabbitMQ is what's used by 95%+ of our community, that's what the development environment should focus on. The patch to remove all of this is here - https://review.openstack.org/#/c/192154/. Expect this to merge by the end of the month. If people are interested in non RabbitMQ external plugins, now is the time to start writing them. The oslo.messaging team already moved their functional test installation for alternative platforms off of devstack, so this should impact a very small number of people. >>> >>> The recent spec we added to define a policy for oslo.messaging drivers is >>> intended as a way to encourage that 5% who feels a different messaging >>> layer is critical to participate upstream by adding devstack-gate jobs >>> and committing developers to keep them stable. This change basically >>> slams the door in their face and says "good luck, we don't actually care >>> about accomodating you." This will drive them more into the shadows, >>> and push their forks even further away from the core of the project. If >>> that's your intention, then we need to have a longer conversation where >>> you explain to me why you feel that's a good thing. >> >> I believe it is not the responsibility of the devstack team to support >> every possible backend one could imagine and carry that technical debt >> in tree, confusing new users in the process that any of these things >> might actually work. I believe that if you feel that your spec assumed >> that was going to be the case, you made a large incorrect externalities >> assumption. >> > > I agree with you, and support your desire to move things into plugins. > > However, your timing is problematic and the lack of coordination with > the ongoing effort to deprecate untested messaging drivers gracefully > is really frustrating. We've been asking (on this list) zmq interested > parties to add devstack-gate jobs and identify themselves as contacts > to support these drivers. Meanwhile this change and the wording around > it suggest that they're not welcome in devstack. So there has clearly been some disconnect here. This patch was originally going to come later in the cycle, but some back and forth on proton fixes with Flavio made me realize we really needed to get this direction out in front of more people (which is why it wasn't just a patch, it was also an email heads up). So there wasn't surprise when it was merged. We built the external plugin mechanism in devstack to make it very easy to extend out of tree, and make it easy to let people consume your out of tree stuff. It's the only way that devstack works in the big tent world, because there just is too much stuff for the team to support. >>> Also, I take issue with the value assigned to dropping it. If that 95% >>> is calculated as orgs_running_on_rabbit/orgs then it's telling a really >>> lop-sided story. I'd rather see compute_nodes_on_rabbit/compute_nodes. >>> >>> I'd like to propose that we leave all of this in tree to match what is >>> in oslo.messaging. I think devstack should follow oslo.messaging and >>> deprecate the ones that oslo.messaging deprecates. Otherwise I feel like >>> we're Vizzini cutting the rope just as The Dread Pirate 0mq is about to >>> climb the last 10 meters to the top of the cliffs of insanity and battle >>> RabbitMQ left handed. I know, "inconceivable" right? >> >> We have an external plugin mechanism for devstack. That's a viable >> option here. People will have to own and do that work, instead of >> expecting the small devstack team to do that for them. I believe I left >> enough of a hook in place that it's possible. >> > > So lets do some communication, and ask for the qpid and zmq people to > step up, and help them move their code into an external plugin, and add > documentation to help their users find it. The burden should shift, but > it still rests with devstack until it _does_ shift. We still need to set a clock, because in the past when we haven't, the burden never shifts. >> That would also let them control the code relevant to their plugin, >> because there is no way that devstack was going to gate against other >> backends here, so we'd end up breaking them pretty often, and it taking >> a while to fix them in tree. > > I love that idea. That is not what the change does though. It deletes > with nary a word about what users of this code should do until new >
Re: [openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack
Excerpts from Sean Dague's message of 2015-06-16 10:16:34 -0700: > On 06/16/2015 12:49 PM, Clint Byrum wrote: > > Excerpts from Sean Dague's message of 2015-06-16 06:22:23 -0700: > >> FYI, > >> > >> One of the things that came out of the summit for Devstack plans going > >> forward is to trim it back to something more opinionated and remove a > >> bunch of low use optionality in the process. > >> > >> One of those branches to be trimmed is all the support for things beyond > >> RabbitMQ in the rpc layer. RabbitMQ is what's used by 95%+ of our > >> community, that's what the development environment should focus on. > >> > >> The patch to remove all of this is here - > >> https://review.openstack.org/#/c/192154/. Expect this to merge by the > >> end of the month. If people are interested in non RabbitMQ external > >> plugins, now is the time to start writing them. The oslo.messaging team > >> already moved their functional test installation for alternative > >> platforms off of devstack, so this should impact a very small number of > >> people. > >> > > > > The recent spec we added to define a policy for oslo.messaging drivers is > > intended as a way to encourage that 5% who feels a different messaging > > layer is critical to participate upstream by adding devstack-gate jobs > > and committing developers to keep them stable. This change basically > > slams the door in their face and says "good luck, we don't actually care > > about accomodating you." This will drive them more into the shadows, > > and push their forks even further away from the core of the project. If > > that's your intention, then we need to have a longer conversation where > > you explain to me why you feel that's a good thing. > > I believe it is not the responsibility of the devstack team to support > every possible backend one could imagine and carry that technical debt > in tree, confusing new users in the process that any of these things > might actually work. I believe that if you feel that your spec assumed > that was going to be the case, you made a large incorrect externalities > assumption. > I agree with you, and support your desire to move things into plugins. However, your timing is problematic and the lack of coordination with the ongoing effort to deprecate untested messaging drivers gracefully is really frustrating. We've been asking (on this list) zmq interested parties to add devstack-gate jobs and identify themselves as contacts to support these drivers. Meanwhile this change and the wording around it suggest that they're not welcome in devstack. > > Also, I take issue with the value assigned to dropping it. If that 95% > > is calculated as orgs_running_on_rabbit/orgs then it's telling a really > > lop-sided story. I'd rather see compute_nodes_on_rabbit/compute_nodes. > > > > I'd like to propose that we leave all of this in tree to match what is > > in oslo.messaging. I think devstack should follow oslo.messaging and > > deprecate the ones that oslo.messaging deprecates. Otherwise I feel like > > we're Vizzini cutting the rope just as The Dread Pirate 0mq is about to > > climb the last 10 meters to the top of the cliffs of insanity and battle > > RabbitMQ left handed. I know, "inconceivable" right? > > We have an external plugin mechanism for devstack. That's a viable > option here. People will have to own and do that work, instead of > expecting the small devstack team to do that for them. I believe I left > enough of a hook in place that it's possible. > So lets do some communication, and ask for the qpid and zmq people to step up, and help them move their code into an external plugin, and add documentation to help their users find it. The burden should shift, but it still rests with devstack until it _does_ shift. > That would also let them control the code relevant to their plugin, > because there is no way that devstack was going to gate against other > backends here, so we'd end up breaking them pretty often, and it taking > a while to fix them in tree. I love that idea. That is not what the change does though. It deletes with nary a word about what users of this code should do until new external plugins appear. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack
On 06/16/2015 12:49 PM, Clint Byrum wrote: > Excerpts from Sean Dague's message of 2015-06-16 06:22:23 -0700: >> FYI, >> >> One of the things that came out of the summit for Devstack plans going >> forward is to trim it back to something more opinionated and remove a >> bunch of low use optionality in the process. >> >> One of those branches to be trimmed is all the support for things beyond >> RabbitMQ in the rpc layer. RabbitMQ is what's used by 95%+ of our >> community, that's what the development environment should focus on. >> >> The patch to remove all of this is here - >> https://review.openstack.org/#/c/192154/. Expect this to merge by the >> end of the month. If people are interested in non RabbitMQ external >> plugins, now is the time to start writing them. The oslo.messaging team >> already moved their functional test installation for alternative >> platforms off of devstack, so this should impact a very small number of >> people. >> > > The recent spec we added to define a policy for oslo.messaging drivers is > intended as a way to encourage that 5% who feels a different messaging > layer is critical to participate upstream by adding devstack-gate jobs > and committing developers to keep them stable. This change basically > slams the door in their face and says "good luck, we don't actually care > about accomodating you." This will drive them more into the shadows, > and push their forks even further away from the core of the project. If > that's your intention, then we need to have a longer conversation where > you explain to me why you feel that's a good thing. I believe it is not the responsibility of the devstack team to support every possible backend one could imagine and carry that technical debt in tree, confusing new users in the process that any of these things might actually work. I believe that if you feel that your spec assumed that was going to be the case, you made a large incorrect externalities assumption. > Also, I take issue with the value assigned to dropping it. If that 95% > is calculated as orgs_running_on_rabbit/orgs then it's telling a really > lop-sided story. I'd rather see compute_nodes_on_rabbit/compute_nodes. > > I'd like to propose that we leave all of this in tree to match what is > in oslo.messaging. I think devstack should follow oslo.messaging and > deprecate the ones that oslo.messaging deprecates. Otherwise I feel like > we're Vizzini cutting the rope just as The Dread Pirate 0mq is about to > climb the last 10 meters to the top of the cliffs of insanity and battle > RabbitMQ left handed. I know, "inconceivable" right? We have an external plugin mechanism for devstack. That's a viable option here. People will have to own and do that work, instead of expecting the small devstack team to do that for them. I believe I left enough of a hook in place that it's possible. That would also let them control the code relevant to their plugin, because there is no way that devstack was going to gate against other backends here, so we'd end up breaking them pretty often, and it taking a while to fix them in tree. -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack
Excerpts from Sean Dague's message of 2015-06-16 06:22:23 -0700: > FYI, > > One of the things that came out of the summit for Devstack plans going > forward is to trim it back to something more opinionated and remove a > bunch of low use optionality in the process. > > One of those branches to be trimmed is all the support for things beyond > RabbitMQ in the rpc layer. RabbitMQ is what's used by 95%+ of our > community, that's what the development environment should focus on. > > The patch to remove all of this is here - > https://review.openstack.org/#/c/192154/. Expect this to merge by the > end of the month. If people are interested in non RabbitMQ external > plugins, now is the time to start writing them. The oslo.messaging team > already moved their functional test installation for alternative > platforms off of devstack, so this should impact a very small number of > people. > The recent spec we added to define a policy for oslo.messaging drivers is intended as a way to encourage that 5% who feels a different messaging layer is critical to participate upstream by adding devstack-gate jobs and committing developers to keep them stable. This change basically slams the door in their face and says "good luck, we don't actually care about accomodating you." This will drive them more into the shadows, and push their forks even further away from the core of the project. If that's your intention, then we need to have a longer conversation where you explain to me why you feel that's a good thing. Also, I take issue with the value assigned to dropping it. If that 95% is calculated as orgs_running_on_rabbit/orgs then it's telling a really lop-sided story. I'd rather see compute_nodes_on_rabbit/compute_nodes. I'd like to propose that we leave all of this in tree to match what is in oslo.messaging. I think devstack should follow oslo.messaging and deprecate the ones that oslo.messaging deprecates. Otherwise I feel like we're Vizzini cutting the rope just as The Dread Pirate 0mq is about to climb the last 10 meters to the top of the cliffs of insanity and battle RabbitMQ left handed. I know, "inconceivable" right? __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack
+1 Sean. -- dims On Tue, Jun 16, 2015 at 9:22 AM, Sean Dague wrote: > FYI, > > One of the things that came out of the summit for Devstack plans going > forward is to trim it back to something more opinionated and remove a > bunch of low use optionality in the process. > > One of those branches to be trimmed is all the support for things beyond > RabbitMQ in the rpc layer. RabbitMQ is what's used by 95%+ of our > community, that's what the development environment should focus on. > > The patch to remove all of this is here - > https://review.openstack.org/#/c/192154/. Expect this to merge by the > end of the month. If people are interested in non RabbitMQ external > plugins, now is the time to start writing them. The oslo.messaging team > already moved their functional test installation for alternative > platforms off of devstack, so this should impact a very small number of > people. > > -Sean > > -- > Sean Dague > http://dague.net > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack
FYI, One of the things that came out of the summit for Devstack plans going forward is to trim it back to something more opinionated and remove a bunch of low use optionality in the process. One of those branches to be trimmed is all the support for things beyond RabbitMQ in the rpc layer. RabbitMQ is what's used by 95%+ of our community, that's what the development environment should focus on. The patch to remove all of this is here - https://review.openstack.org/#/c/192154/. Expect this to merge by the end of the month. If people are interested in non RabbitMQ external plugins, now is the time to start writing them. The oslo.messaging team already moved their functional test installation for alternative platforms off of devstack, so this should impact a very small number of people. -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
