Open Stack

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