Michael Still <[email protected]> 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 _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
