On 08/01/2014 03:29 PM, Ken Giusti wrote: > 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 :)
+1 As long as we get the tests running, I'm happy. This sounds like something more acceptable for the infrastructure - at least based on the discussions on this thread. The plan sounds good to me. I think it's also possible to run amqp10 gate *just* for the changes happening in the *amqp* package but it's probably worth it to just make it non-voting and run it for every patch, as you mentioned. Flavio -- @flaper87 Flavio Percoco _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
