<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Jun 19, 2015 at 2:15 AM Flavio Percoco <<a href="mailto:flavio@redhat.com">flavio@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 18/06/15 16:37 -0400, Doug Hellmann wrote:<br>
>Excerpts from Clint Byrum's message of 2015-06-18 12:47:21 -0700:<br>
>> Hello! I know there's been a lot of churn and misunderstanding over the<br>
>> recent devstack changes, so I wanted to make it clear where we're going<br>
>> with messaging drivers now that the policy [1] was approved.<br>
>><br>
>> According to the policy, drivers need to have at least 60% unit test<br>
>> coverage, and an integration test suite with at least 3 "popular"<br>
>> OpenStack projects, with preference for Nova, Cinder, and Glance, and<br>
>> individuals who will support said test suite.<br>
>><br>
>> So, with that, the following is the status of each driver in tree right<br>
>> now:<br>
>><br>
>> rabbit - 89% Unit test coverage. Being the default in devstack, and<br>
>> the default in nearly every project's config files, this one is heavily<br>
>> integration tested. There are multiple individuals who have proven to<br>
>> be able to debug failures related to RabbitMQ and are well known in<br>
>> the community.<br>
><br>
>+1<br>
><br>
>><br>
>> qpid - Unit test coverage is at 77%, so it passes that bar. I cannot<br>
>> find any integration testing being done, so it fails that. I also have<br>
>> not found anyone who will step up and support it. So this should be<br>
>> deprecated immediately.<br>
><br>
>+1 - I believe Ken and the other folks interested in this indicated that<br>
>the AMQP 1.0 driver should replace this one.<br>
<br>
The qpid driver should be deprecated, I'll be doing so in the next<br>
couple of days. Look forward to the patch.<br>
<br></blockquote><div>+1<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br>
>Speaking of AMQP 1.0, you don't mention that one (it uses qpid, but is<br>
>separate from the driver named "qpid").<br>
<br>
I'd like to clarify something about the AMQP 1.0 driver. It's not a<br>
direct replacement for the qpidd one because it uses an entirely<br>
different protocol that recently became a standard.<br>
<br>
The reason I mention this is because it doesn't really require qpidd -<br>
not the double d - which is the broker daemon in the qpid family. I<br>
guess the confusion comes because the library it sits on top off is<br>
called qpid-proton.<br>
<br>
The qpid family is a set of tools that provide messaging capabilities.<br>
Among those you find qpidd (broker daemon), qpid-proton (amqp1.0<br>
library), qpid-dispatch (message router). It's confusing indeed.<br>
<br>
The importance of this distinction is that the amqp1.0 driver in<br>
oslo.messaging is intended as a protocol based driver and not<br>
targetting any technology. That is to say, that it could be written<br>
using a library that is not qpid-proton and it can talk to any message<br>
router or message broker that has support for amqp 1.0.<br>
<br></blockquote><div><br></div><div>+1 - yeah, we really shouldn't be considering the amqp1 driver as simply the "replacement qpid driver" - as Flavio points out it has the potential to provide compatibility with other messaging back ends. <br><br></div><div>Clint - can you also include separate metrics for the amqp1 driver?  <br><br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The ones we're targetting for the gate are rabbitmq (with the amqp 1.0<br>
plugin enabled) and qpidd.<br>
<br>
Since we're at it, let me share some updates:<br>
<br>
The driver unittests now run on every python2 job and the work on<br>
python3 is almost done. There's also a functional tests gate like we<br>
have for other drivers.<br>
<br>
The missing bit is an integration gate, which we'll be start working<br>
on in the next couple of days.<br>
<br>
Hope the above helps clarifying confusions around this driver.<br>
<br>
><br>
>><br>
>> zmq - Unit test coverage is 74%. There are no currently active integration<br>
>> tests in OpenStack's infrastructure. Several individuals have self<br>
>> identified as being willing to work on creating them. We have not had<br>
>> the conversations yet about ongoing support. I recommend we continue to<br>
>> support their effort to become policy compliant. If that does not solidify<br>
>> by M3 of Liberty, or if the "new" zmq driver appears with integration<br>
>> tests and support manpower, then we can deprecate at that time.<br>
><br>
>+1 - I know interest has been growing in this, so let's keep it going<br>
>and see where we end up.<br>
><br>
>><br>
>> There's also the question of _how_ to deprecate them. I figure we should<br>
>> deprecate when the driver is loaded. Is there an existing mechanism<br>
>> that someone can point me to, or should I look at adding that to<br>
>> oslo.messaging/stevedore?<br>
><br>
>Normally we would recommend using versionutils from oslo.log, but we've<br>
>been trying to avoid making oslo.log a dependency of the oslo libs<br>
>because it uses some of them and that introduces cycles. Dims had a<br>
>patch recently that just used a DeprecationWarning, and relied on<br>
>oslo.log to redirect the warning to the log file. That seems like a good<br>
>pattern to repeat.<br>
<br>
Can we use debtcollector to decorate the main driver class? A warning<br>
will be printted every time an instance of such class is created<br>
(rather than at import time).<br>
<br>
If we don't want to add a dependency on that, we could just use a<br>
DeprecationWarning as Doug mentioned.<br>
<br>
><br>
>Doug<br>
><br>
>><br>
>> [1] <a href="http://specs.openstack.org/openstack/openstack-specs/specs/supported-messaging-drivers.html" rel="noreferrer" target="_blank">http://specs.openstack.org/openstack/openstack-specs/specs/supported-messaging-drivers.html</a><br>
>><br>
><br>
>__________________________________________________________________________<br>
>OpenStack Development Mailing List (not for usage questions)<br>
>Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
--<br>
@flaper87<br>
Flavio Percoco<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div>