<div dir="ltr">On Wed, 30 Jul 2014 22:14:51 +0000, Jeremy Stanley wrote:<br>>On 2014-07-30 14:59:09 -0400 (-0400), Ken Giusti wrote:<br>>> Thanks Daniel.  It was my understanding - which may be wrong - that<br>>> having devstack install the 'out of band' packages would only help in<br>
>> the case of the devstack-based integration tests, not in the case of<br>>> CI running the unit tests.  Is that indeed the case?<br>>[...]<br>>> I'm open to any thoughts on how best to solve this, thanks.<br>
><br>>Since they're in EPEL and we run Python 2.6 unit tests today on<br>>CentOS 6 servers, if the proton libraries install successfully there<br>>perhaps we could opportunistically exercise it only under Python 2.6<br>
>for now? Not ideal, but it does get it enforced upstream with<br>>minimal fuss. I'd really rather not start accumulating arbitrary PPA<br>>sources on our job workers... I know we've done it for a handful of<br>
>multi-project efforts where we needed select backports from non-LTS<br>>releases, but we've so far limited that to only PPAs maintained by<br>>the same package teams as the mainline distro packages themselves.<br>
><br><br>Yeah, it's becoming pretty clear that adding this PPA to infra is not<br>The Right Thing To Do.  How does this sound as an alternative:<br><br>1) _for_ _now_, make the dependent unit tests optional for<br>
oslo.messaging.  Specifically, by default tox will not run them, but<br>I'll add a new testenv that adds a requirement for the dependent<br>packages and runs all the unit tests (default tests + new amqp1.0<br>tests).  Eg, do 'tox -e amqp1' to pull in the python packages that<br>
require the libraries, and run all unit tests.  This allows those<br>developers that have installed the proton libraries to run the tests,<br>and avoid making life hard for those devs who don't have the libraries<br>installed.<br>
<br>2) Propose a new optional configuration flag in devstack that enables<br>the AMQP 1.0 messaging protocol (default off).  Something like<br>$RPC_MESSAGING_PROTOCOL == "AMQP1".  When this is set in the devstack<br>
config, rpc_backend will install the AMQP 1.0 libraries, adding the<br>Qpid PPA in the case of ubuntu for now.<br><br>3) Create a non-voting oslo.messaging gate test [0] that merely<br>runs the 'tox -e amqp1' tests.  Of course, additional integration<br>
tests are a Good Thing, but at the very least we should start with<br>this. This would give us a heads up should new patches break the amqp<br>1.0 driver.  This test could eventually become gating once the driver<br>matures and the packages find their way into all the proper repos.<br>
<br>4) Profit (couldn't resist :)<br><br>Opinions?<br><br>[0] I honestly have no idea how to do this, or if it's even feasible<br>btw - I've never written a gating test before.  I'd appreciate any<br>pointers to get me started, thanks!<br>
<br><br>>Longer term, I'd suggest getting it sponsored into Debian<br>>unstable/testing ASAP, interesting the Ubuntu OpenStack team in<br>>importing it into the development tree for the next Ubuntu release,<br>
>and then incorporating it into the Trusty Ubuntu Cloud Archive.<br>>We're not using UCA yet, but on Trusty we probably should consider<br>>adding it sooner rather than later since when we tried to tack on<br>
>the Precise UCA in the last couple cycles we had too many headaches<br>>from trying to jump ahead substantially on fundamental bits like<br>>libvirt. Breaking sooner and more often means those incremental<br>>issues are easier to identify and address, usually.<br>
<br>Ah - I didn't know that, thanks!  I know one of the Qpid devs is<br>currently engaged in getting these packages into Debian.  I'll reach<br>out to him and see if he can work on getting it into UCA next.<br><br>
Thanks again - very valuable info!<br><br>>--<br>>Jeremy Stanley<br><br clear="all"><br>-- <br>Ken Giusti  (<a href="mailto:kgiusti@gmail.com">kgiusti@gmail.com</a>)
</div>