<div dir="ltr"><div><div><div>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.<br><br></div>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!<br><br></div>That said, the only concern I have with this patch is whether it will result in a less well-tested oslo.messaging.<br><br></div>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.<br><div><div><br>[0] <a href="https://github.com/kgiusti/amqp1-devstack">https://github.com/kgiusti/amqp1-devstack</a><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jun 18, 2015 at 12:28 PM Clint Byrum <<a href="mailto:clint@fewbar.com">clint@fewbar.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Sean Dague's message of 2015-06-18 07:09:56 -0700:<br>
> On 06/18/2015 09:54 AM, ozamiatin wrote:<br>
> > Hi Sean,<br>
> ><br>
> > Thanks a lot for the plugin!<br>
> > I was a little bit confused with a commit message and dropping of<br>
> > drivers support.<br>
> > It turns really not so hard to test zeromq driver with plugin.<br>
><br>
> Yes, that was the design goal with the whole plugin mechanism. To<br>
> provide an experience that was so minimally different from vanilla<br>
> devstack, that most people would never even notice. It's honestly often<br>
> easier to explain to people how to enable a service via a plugin than<br>
> the config variables in tree.<br>
><br>
<br>
+1<br>
<br>
> > So I have no objections any more and removing my -1.<br>
><br>
> Cool, great. It would be great if you or someone else could post a<br>
> review to pull this code into gerrit somewhere. You'll need the code in<br>
> gerrit to use it in devstack-gate jobs, as we don't allow projects<br>
> outside of gerrit to be cloned during tests.<br>
><br>
> > But I also agree with Doug Hellmann and other speakers that we should<br>
> > not make such changes<br>
> > so fast.<br>
><br>
> The reason I didn't think the time table was unreasonable was how quick<br>
> this transition could be made, and how little code is needed to make one<br>
> of these plugins. And the fact that from there on out you get to be in<br>
> control of landing fixes or enhancements for your backend on the<br>
> timetable that works for you.<br>
><br>
> It will make getting the devstack-gate jobs working reliably a lot<br>
> simpler and quicker for your team.<br>
><br>
<br>
Agreed on all points. I believe that the mistake was simply that<br>
there wasn't any need to hold hands for those who we are enabling to<br>
move faster and more independently. We do, in fact, need to transfer<br>
ownership gracefully. Thanks so much for writing the plugin for zmq,<br>
that is a huge win for zmq developers. I can't speak for oslo directly,<br>
but it seems like that plugin should land under oslo's direct stewardship<br>
and then we can move forward with this.<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div>