Open Stack

Clint Byrum wrote:
> Excerpts from Flavio Percoco's message of 2015-06-18 23:14:49 -0700:
>> On 18/06/15 16:37 -0400, Doug Hellmann wrote:
>>> Excerpts from Clint Byrum's message of 2015-06-18 12:47:21 -0700:
>>>> Hello! I know there's been a lot of churn and misunderstanding over the
>>>> recent devstack changes, so I wanted to make it clear where we're going
>>>> with messaging drivers now that the policy [1] was approved.
>>>>
>>>> According to the policy, drivers need to have at least 60% unit test
>>>> coverage, and an integration test suite with at least 3 "popular"
>>>> OpenStack projects, with preference for Nova, Cinder, and Glance, and
>>>> individuals who will support said test suite.
>>>>
>>>> So, with that, the following is the status of each driver in tree right
>>>> now:
>>>>
>>>> rabbit - 89% Unit test coverage. Being the default in devstack, and
>>>> the default in nearly every project's config files, this one is heavily
>>>> integration tested. There are multiple individuals who have proven to
>>>> be able to debug failures related to RabbitMQ and are well known in
>>>> the community.
>>> +1
>>>
>>>> qpid - Unit test coverage is at 77%, so it passes that bar. I cannot
>>>> find any integration testing being done, so it fails that. I also have
>>>> not found anyone who will step up and support it. So this should be
>>>> deprecated immediately.
>>> +1 - I believe Ken and the other folks interested in this indicated that
>>> the AMQP 1.0 driver should replace this one.
>> The qpid driver should be deprecated, I'll be doing so in the next
>> couple of days. Look forward to the patch.
>>
>>> Speaking of AMQP 1.0, you don't mention that one (it uses qpid, but is
>>> separate from the driver named "qpid").
>> I'd like to clarify something about the AMQP 1.0 driver. It's not a
>> direct replacement for the qpidd one because it uses an entirely
>> different protocol that recently became a standard.
>>
>
> Could you clarify where the code actually is, or more specifically, why
> the code doesn't follow the same organization as the others? There's no
> "impl_amqp" and the tests don't live in tests/drivers, but in
> tests/test_amqp_driver. I left it out because I didn't realize this new
> driver lived in tree.
>
> Anyway, this driver appears to land in the "prospective drivers" category
> in the spec. We failed to call out drivers that are still considered
> experimental, however I kind of feel like the driver should be out
> of tree until such time as it is usable enough that it _could_ have an
> integration test.
>
> So, is it feasible that this driver will fall in-line with the others in
> the next 6 months, or should we be looking at either revising the
> policy, or moving it out of tree until it is capable of that?
>
>> The reason I mention this is because it doesn't really require qpidd -
>> not the double d - which is the broker daemon in the qpid family. I
>> guess the confusion comes because the library it sits on top off is
>> called qpid-proton.
>>
>> The qpid family is a set of tools that provide messaging capabilities.
>> Among those you find qpidd (broker daemon), qpid-proton (amqp1.0
>> library), qpid-dispatch (message router). It's confusing indeed.
>>
>> The importance of this distinction is that the amqp1.0 driver in
>> oslo.messaging is intended as a protocol based driver and not
>> targetting any technology. That is to say, that it could be written
>> using a library that is not qpid-proton and it can talk to any message
>> router or message broker that has support for amqp 1.0.
>>
>> The ones we're targetting for the gate are rabbitmq (with the amqp 1.0
>> plugin enabled) and qpidd.
>>
>> Since we're at it, let me share some updates:
>>
>> The driver unittests now run on every python2 job and the work on
>> python3 is almost done. There's also a functional tests gate like we
>> have for other drivers.
>>
>> The missing bit is an integration gate, which we'll be start working
>> on in the next couple of days.
>>
>> Hope the above helps clarifying confusions around this driver.
>>
>
> That definitely clarifies the vision, thanks for sharing.
>
>>>> There's also the question of _how_ to deprecate them. I figure we should
>>>> deprecate when the driver is loaded. Is there an existing mechanism
>>>> that someone can point me to, or should I look at adding that to
>>>> oslo.messaging/stevedore?
>>> Normally we would recommend using versionutils from oslo.log, but we've
>>> been trying to avoid making oslo.log a dependency of the oslo libs
>>> because it uses some of them and that introduces cycles. Dims had a
>>> patch recently that just used a DeprecationWarning, and relied on
>>> oslo.log to redirect the warning to the log file. That seems like a good
>>> pattern to repeat.
>> Can we use debtcollector to decorate the main driver class? A warning
>> will be printted every time an instance of such class is created
>> (rather than at import time).
>>
>> If we don't want to add a dependency on that, we could just use a
>> DeprecationWarning as Doug mentioned.
>>
>
>  From a user perspective, as long as it only warns once per invocation of
> the consuming process (so it should warn when nova-conductor starts, not
> when nova-conductor sends a message), then I think we should just use
> DeprecationWarning's because they're relatively simple. Unless I'm
> missing something magical that debtcollector does.

Nothing magical, just hopefully helpful/useful code :-P

>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev