[openstack-dev] [oslo]: some functional tests for the olso.messaging API

Doug Hellmann doug.hellmann at dreamhost.com
Mon Mar 31 15:11:09 UTC 2014

On Mon, Mar 31, 2014 at 8:54 AM, Gordon Sim <gsim at redhat.com> wrote:

> I have recently been trying to get some API level functional tests for the
> olso.messaging library. The idea is that these tests could be run with any
> driver and configured 'backend' and would test the basic functional
> guarantees that the API makes.

This sounds like a good idea, thanks for tackling it!

> I have an initial set of such tests now. The url use is set via an
> environment variable, so e.g.
> TRANSPORT_URL=rabbit:// python -m testtools.run
> functional_tests.test_functional.NotifyTests
> would run the notify tests against a local rabbit broker on the standard
> port. If attached the tests here, but if there is interest in including
> these in the repo, I'll create a proper changeset for review and comments.
> I've run these tests against the qpid and rabbit drivers as well as the
> new AMQP 1.0 based driver available for initial review[1]. For rabbit and
> qpid there is one failure, where the exchange specified in the target is
> ignored. I'll be running them against the 0mq driver also.
> At present, against rabbit and qpid, the tests work only if each test is
> run in isolation. This is because there appears to be no way through the
> API to have subscriptions created by the driver to be dropped, short of
> killing the process[2].

> There may be some step my tests aren't doing that would trigger proper
> cleanup. This may also not be that important to real world uses of the
> library(?) and is only a minor irritation from the testing pov. However if
> there is interest, and assuming it is indeed an issue and not just a
> misunderstanding on my part,I can try and get a patch up for review to
> address it.

I can see where that would be useful in some apps, so let's see if we can
make the API support it.

Another slight annoyance from the testing pov is that the API provides no
> way of determining when a server is 'ready' i.e. when its subscriptions are
> in place. I had to work around this for qpid and rabbit with a short sleep,
> which is always a bit nasty.

Are you saying that creating the subscription doesn't block until it is

> The last issue to mention here is that stop() implementation doesn't
> signal the driver in any way. So to actually get it to stop, at least for
> the blocking executor, you have to send a dummy message after calling
> stop() in order to have the poll() on the listener return and allow the
> detection of the stop flag. This is easy enough to work around in the tests
> and is a lot less nasty than the sleep.

That sounds like it would be useful, too, so apps can cleanly disconnect
from the broker.


> --Gordon.
> [1] https://review.openstack.org/#/c/75815/
> [2] The cleanup() impl for both drivers simply closes any free connections
> in the pool
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140331/d3d36c23/attachment.html>

More information about the OpenStack-dev mailing list