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

Reply via email to