[openstack-dev] [all] [qpid] [zmq] [RabbitMQ] [oslo] Pending deprecation of driver(s).

Flavio Percoco flavio at redhat.com
Sat Jun 20 13:34:04 UTC 2015

On 19/06/15 13:43 -0700, Clint Byrum wrote:
>Excerpts from Flavio Percoco's message of 2015-06-18 23:14:49 -0700:
>> 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.

As Ken mentioned in a different email, the amqp driver was created as
a protocol specific driver rather than a "technology (as in software)"
based driver. Therefore, at the time, it was decided to put it in a
different package to separate it from others.

Now that you mentioned this, we could really move out of protocols and
rename the `amqp` package into `impl_amqp` but still keep it as a

TBH, I prefer using packages to organize these drivers since some of
them (or all?) require more than one module to be implemented.

>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?

Yes, I'm confident this will happen. It went from having a single gate
running funcitonal tests to running unittests in all gates but python3
(this will be solved in the next week or two) and the original
functional gate.

The team is working on adding an integrated gate for this driver as
well. If by the time the freeze is coming the driver is still not
running integrated tests, I'd agree on removing it.

As it stands right now, it is moving on the right direction.


>> 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.

I don't think you're missing anything. I'm asking because this is what
debtcollator was created for.

Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150620/3566ec7f/attachment.pgp>

More information about the OpenStack-dev mailing list