Open Stack

Flavio Percoco wrote:
> 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.
>
> 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.
>
>>
>>>
>>> zmq - Unit test coverage is 74%. There are no currently active
>>> integration
>>> tests in OpenStack's infrastructure. Several individuals have self
>>> identified as being willing to work on creating them. We have not had
>>> the conversations yet about ongoing support. I recommend we continue to
>>> support their effort to become policy compliant. If that does not
>>> solidify
>>> by M3 of Liberty, or if the "new" zmq driver appears with integration
>>> tests and support manpower, then we can deprecate at that time.
>>
>> +1 - I know interest has been growing in this, so let's keep it going
>> and see where we end up.
>>
>>>
>>> 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).

Seems fair to me:

http://docs.openstack.org/developer/debtcollector/api.html#debtcollector.removals.remove 
(which itself uses a deprecation warning...).

>
> If we don't want to add a dependency on that, we could just use a
> DeprecationWarning as Doug mentioned.
>
>>
>> Doug
>>
>>>
>>> [1]
>>> http://specs.openstack.org/openstack/openstack-specs/specs/supported-messaging-drivers.html
>>>
>>>
>>
>> __________________________________________________________________________
>>
>> 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
>
> __________________________________________________________________________
> 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