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: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
