On 7/30/2014 11:59 AM, Ken Giusti wrote:
On Wed, 30 Jul 2014 14:25:46 +0100, Daniel P. Berrange wrote:
On Wed, Jul 30, 2014 at 08:54:01AM -0400, Ken Giusti wrote:
Greetings,

Apologies for the cross-post: this should be of interest to both infra
and olso.messaging developers.

The blueprint [0] that adds support for version 1.0 of the AMQP messaging
protocol is blocked due to CI test failures [1]. These failures are due
to a new package dependency this blueprint adds to oslo.messaging.

The AMQP 1.0 functionality is provided by the Apache Qpid's Proton
AMQP 1.0 toolkit.  The blueprint uses the Python bindings for this
toolkit, which are available on Pypi.  These bindings, however, include
a C extension that depends on the Proton toolkit development libraries
in order to build and install.  The lack of this toolkit is the cause
of the blueprint's current CI failures.

This toolkit is written in C, and thus requires platform-specific
libraries.

Now here's the problem: packages for Proton are not included by
default in most distro's base repositories (yet).  The Apache Qpid
team has provided packages for EPEL, and has a PPA available for
Ubuntu.  Packages for Debian are also being proposed.

I'm proposing this patch to openstack-infra/config to address the
dependency problem [2].  It adds the proton toolkit packages to the
common slave configuration.  Does this make sense?  Are there any
better alternatives?

For other cases where we need more native packages, we tyically
use devstack to ensure they are installed. This is preferrable
since it works for ordinary developers as well as the CI system.


Thanks Daniel.  It was my understanding - which may be wrong - that
having devstack install the 'out of band' packages would only help in
the case of the devstack-based integration tests, not in the case of
CI running the unit tests.  Is that indeed the case?

At this point, there are no integration tests that exercise the
driver.  However, the new unit tests include a test 'broker', which
allow the unit tests to fully exercise the new driver, right down to
the network.  That's a bonus of AMQP 1.0 - it can support peer-2-peer
messaging.

So its the new unit tests that have the 'hard' requirement of the
proton libraries.    And mocking-out the proton libraries really
doesn't allow us to do any meaningful tests of the driver.

But if devstack is the preferred method for getting 'special case'
packages installed, would it be acceptable to have the new unit tests
run as a separate oslo.messaging integration test, and remove them
from the unit tests?

I'm open to any thoughts on how best to solve this, thanks.

Regards,
Daniel
--
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


If your unit tests are dependent on a specific dependent library aren't they no longer unit tests but integration tests anyway?

Just wondering, not trying to put up road-blocks because I'd like to see how this code performs but haven't had time yet to play with it.

--

Thanks,

Matt Riedemann


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to