Open Stack

On 08/09/2014 12:33 PM, Jeremy Stanley wrote:
> On 2014-08-08 09:06:29 -0400 (-0400), Russell Bryant wrote:
> [...]
>> We've seen several times that building and maintaining 3rd party
>> CI is a *lot* of work.
> 
> Building and maintaining *any* CI is a *lot* of work, not the least
> of which is the official OpenStack project CI (I believe Monty
> mentioned in #openstack-infra last night that our CI is about twice
> the size of Travis-CI now, not sure what metric he's comparing there
> though).

Dang, I'd love to see those numbers.  :-)

>> Like you said in [1], doing this in infra's CI would be ideal. I
>> think 3rd party should be reserved for when running it in the
>> project's infrastructure is not an option for some reason
>> (requires proprietary hw or sw, for example).
> 
> Add to the "not an option for some reason" list, software which is
> not easily obtainable through typical installation channels (PyPI,
> Linux distro-managed package repositories for their LTS/server
> releases, et cetera) or which requires gyrations which destabilize
> or significantly complicate maintenance of the overall system as
> well as reproducibility for developers. It may be possible to work
> around some of these concerns via access from multiple locations
> coupled with heavy caching, but adding that in for a one-off source
> is hard to justify the additional complexity too.

Understood.  Some questions ... is building an image that has libvirt
and qemu pre-installed from source good enough?  It avoids the
dependency on job runs, but moves it to image build time though, so it
still exists.

If the above still doesn't seem like a workable setup, then I think we
should just go straight to an image with fedora + virt-preview repo,
which kind of sounds easier, anyway.

-- 
Russell Bryant