Open Stack

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  (kgiusti at gmail.com)