On 09/19/2014 08:38 AM, Ken Giusti wrote: > 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?
On the point of non-core developers being better able to contribute, in oslo-incubator we have the concept of Maintainers, who have sort of a super +1 that counts as +2 on the code they maintain (note that this is a policy thing, not something enforced by Gerrit in any way). What this means is that in theory you could have two +1's from maintainers and then all you need an oslo.messaging core for is the approval. In practice I think it's more common that you get a maintainer +1 and a core +2A, but for oslo.messaging drivers where there is likely to be more than one person interested in maintaining it the two +1 case might be more common. In any case, that might be an option besides splitting out the drivers completely. > >> 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 > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev