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: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
