On 04/11/2014 04:58 PM, Sean Dague wrote: > On 04/11/2014 04:39 PM, Russell Bryant wrote: >> On 04/11/2014 04:29 PM, Eric Windisch wrote: >>> >>> What I hope to do is setup a check doing CI on devstack-f20 >>> nodes[3], this will setup a devstack based nova with the >>> nova-docker driver and can then run what ever tests make sense >>> (currently only a minimal test, Eric I believe you were looking >>> at tempest support maybe it could be hooked in here?). >>> >>> >>> I'm not sure how far you've gotten, but my approach had been >>> not to use devstack-gate, but to build upon dockenstack >>> (https://github.com/ewindisch/dockenstack) to hasten the >>> tests. >>> >>> Advantages to this over devstack-gate are that: 1) It is usable >>> for developers as an alternative to devstack-vagrant so it may >>> be the same environment for developing as for CI. 2) All >>> network-dependent resources are downloaded into the image - >>> completely eliminating the need for mirrors/caching >>> infrastructure. 3) Most of the packages are installed and >>> pre-configured inside the image prior to running the tests such >>> that there is little time spent initializing the testing >>> environment. >>> >>> Disadvantages are: 1) It's currently tied to Ubuntu. It could >>> be ported to Fedora, but hasn't been. 2) Removal of apt/rpm or >>> even pypi dependencies may allow for false-positive testing >>> results (if a dependency is removed from a requirements.txt or >>> devstack's packages lists, it will still be installed within >>> the testing image); This is something that could be easily >>> fixed if should it be essential. >>> >>> If you're interested, I'd be willing to entertain adding Fedora >>> support to Dockenstack. >> >> I think part of the issue is how quickly we can get this working >> in OpenStack infra. devstack-gate and devstack are how most >> (all?) functional test jobs work there today. > > Correct. If this is intended for infra, it has to use > devstack-gate. That has lots of levers that we need to set based on > branches, how to do the zuul ref calculations (needed for the > speculative gating), how to do branch overrides for stable an > upgrade jobs, etc. > > If we think it's staying in 3rd party, people are free to use > whatever they would like.
I guess we should be clear on this point. I *really* think the best way forward is to move back to trying to get this working in openstack infra. I really can't think of any reason not to. Any disagreements with that goal? -- Russell Bryant _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev