Open Stack

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
>