Open Stack

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