[openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack

Ken Giusti kgiusti at gmail.com
Fri Jun 19 19:16:27 UTC 2015


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 <clint at fewbar.com> 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150619/420b3afd/attachment.html>


More information about the OpenStack-dev mailing list