Open Stack

Michael Still <mikal at stillhq.com> writes:

> Agreed, where it makes sense. In general we should be avoiding third
> party CI unless we need to support something we can't in the gate -- a
> proprietary virt driver, or weird network hardware for example. I
> think we've now well and truly demonstrated that third party CI
> implementations are hard to run well.
>
> Docker doesn't meet either of those tests.
>
> However, I can see third party CI being a stepping stone required by
> the infra team to reduce their workload -- in other words that they'd
> like to see things running consistently as a third party CI before
> they move it into their world. However, I'll leave that call to the
> infra team.

Well put, Michael and Russel.  We see the test infrastructure as a
commons that helps enable new projects join the community.  Any tests
that involve open source components that physically can run in the
project infrastructure almost certainly should.  That helps with
repeatability, maintenance, and integration into the OpenStack community
and eventually project.

As far as workload goes, I wouldn't ask for a third-party CI setup first
to demonstrate viability because as you say, it's quite a bit of work.
What would be very helpful is to try to do as much local testing of
proposed jobs before submitting a review to infra to add the job.  Most
folks are pretty good about that already.  Also, reviews of jobs changes
are always welcome in the openstack-infra/config repository!  Both of
those things will help with infra review workload tremendously, and
still take less time than running private infrastructure.

I look forward to seeing docker tests running in OpenStack
infrastructure soon.

Thanks,

Jim