Open Stack

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