[openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack
ozamiatin at mirantis.com
Thu Jun 18 07:28:21 UTC 2015
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.
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:
>>>> 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
>>> 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
> 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-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev