Open Stack

On Wed, 30 Jul 2014 22:14:51 +0000, Jeremy Stanley wrote:
>On 2014-07-30 14:59:09 -0400 (-0400), Ken Giusti wrote:
>> 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?
>[...]
>> I'm open to any thoughts on how best to solve this, thanks.
>
>Since they're in EPEL and we run Python 2.6 unit tests today on
>CentOS 6 servers, if the proton libraries install successfully there
>perhaps we could opportunistically exercise it only under Python 2.6
>for now? Not ideal, but it does get it enforced upstream with
>minimal fuss. I'd really rather not start accumulating arbitrary PPA
>sources on our job workers... I know we've done it for a handful of
>multi-project efforts where we needed select backports from non-LTS
>releases, but we've so far limited that to only PPAs maintained by
>the same package teams as the mainline distro packages themselves.
>

Yeah, it's becoming pretty clear that adding this PPA to infra is not
The Right Thing To Do.  How does this sound as an alternative:

1) _for_ _now_, make the dependent unit tests optional for
oslo.messaging.  Specifically, by default tox will not run them, but
I'll add a new testenv that adds a requirement for the dependent
packages and runs all the unit tests (default tests + new amqp1.0
tests).  Eg, do 'tox -e amqp1' to pull in the python packages that
require the libraries, and run all unit tests.  This allows those
developers that have installed the proton libraries to run the tests,
and avoid making life hard for those devs who don't have the libraries
installed.

2) Propose a new optional configuration flag in devstack that enables
the AMQP 1.0 messaging protocol (default off).  Something like
$RPC_MESSAGING_PROTOCOL == "AMQP1".  When this is set in the devstack
config, rpc_backend will install the AMQP 1.0 libraries, adding the
Qpid PPA in the case of ubuntu for now.

3) Create a non-voting oslo.messaging gate test [0] that merely
runs the 'tox -e amqp1' tests.  Of course, additional integration
tests are a Good Thing, but at the very least we should start with
this. This would give us a heads up should new patches break the amqp
1.0 driver.  This test could eventually become gating once the driver
matures and the packages find their way into all the proper repos.

4) Profit (couldn't resist :)

Opinions?

[0] I honestly have no idea how to do this, or if it's even feasible
btw - I've never written a gating test before.  I'd appreciate any
pointers to get me started, thanks!


>Longer term, I'd suggest getting it sponsored into Debian
>unstable/testing ASAP, interesting the Ubuntu OpenStack team in
>importing it into the development tree for the next Ubuntu release,
>and then incorporating it into the Trusty Ubuntu Cloud Archive.
>We're not using UCA yet, but on Trusty we probably should consider
>adding it sooner rather than later since when we tried to tack on
>the Precise UCA in the last couple cycles we had too many headaches
>from trying to jump ahead substantially on fundamental bits like
>libvirt. Breaking sooner and more often means those incremental
>issues are easier to identify and address, usually.

Ah - I didn't know that, thanks!  I know one of the Qpid devs is
currently engaged in getting these packages into Debian.  I'll reach
out to him and see if he can work on getting it into UCA next.

Thanks again - very valuable info!

>--
>Jeremy Stanley


-- 
Ken Giusti  (kgiusti at gmail.com)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140801/de665cdb/attachment.html>