On Thu, 18 Sep 2014 17:29:27 Eric Windisch wrote: >> >> >> That?s great feedback, Eric, thank you. I know some of the other projects
+1 - yes, excellent feedback - having just worked on the AMQP 1.0 driver, I think you've nicely described some of my own experiences. >> are moving drivers out of the main core tree, and we could certainly >> consider doing that here as well, if we have teams willing to sign up for >> the work it means doing. >> >> In addition to the zmq driver, we have a fairly stable rabbit driver, a >> qpid driver whose quality I don?t know , and a new experimental AMQP 1.0 >> driver. Are we talking about moving those out, too, or just zmq because we >> were already considering removing it entirely? >> > >I believe it makes good sense for all drivers, in the long term. However, >the most immediate benefits would be in offloading any drivers that need >substantial work or improvements, aka velocity. That would mean the AMQP >and ZeroMQ drivers. > I'm tentatively in favor of this - 'tentative' because, noob that I am, I'm not sure I understand the trade-offs, if any, that moving these drivers outside of oslo.messaging would bring. To be clear: I'm 100% for any change that makes it easier to have non-core developers that have the proper domain knowledge contribute to these drivers. However, there's a few things I need to understand: Does this move make it harder for users to deploy these drivers? How would we insure that the proper, tested version of a driver is delivered along with oslo.messaging proper? >With the Nova drivers, what's useful is that we have tempest and we can use >that as an integration gate. I suppose that's technically possible with >oslo.messaging and its drivers as well, although I prefer to see a >separation of concerns were I presume there are messaging patterns you want >to validate that aren't exercised by Tempest. This is critical IMHO - any proposed changes to oslo.messaging proper, or any particular driver for that matter, needs to be vetted against the other out-of-tree drivers automagically. E.g. If a proposed change to oslo.messaging breaks the out of tree AMQP 1.0 driver, that needs to be flagged by jenkins during the gerrit review of the proposed oslo.messaging patch. > >Another thing I'll note is that before pulling Ironic in, Nova had an API >contract test. This can be useful for making sure that changes in the >upstream project doesn't break drivers, or that breakages could at least >invoke action by the driver team: >https://github.com/openstack/nova/blob/4ce3f55d169290015063131134f93fca236807ed/nova/tests/virt/test_ironic_api_contracts.py > >-- >Regards, >Eric Windisch -- Ken Giusti (kgiu...@gmail.com) _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
