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 (kgiu...@gmail.com)
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev