Open Stack

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).

> 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.

> I wonder if the job could be as simple as one with an added step
> in the config to install latest libvirt from source.  Dan, do you
> think someone could add a libvirt-current.tar.gz to
> http://libvirt.org/sources/ ? Using the latest release seems
> better than master from git.
[...]

Would getting it into EPEL for CentOS 7 or UCA for Ubuntu 14.04 LTS
hopefully be an option?
-- 
Jeremy Stanley