Open Stack

On 3 July 2014 02:44, Michael Still <mikal at stillhq.com> wrote:

> I have seen both. Normally there's a failure, reviewers notice, and
> then the developer spins trying out fixes by uploading new patch sets.
>

Interesting. Yes, I can see that you need fast response from CIs to support
that scenario. 12-hour edit-compile-run loop will ruin anybody's
day/week/month.

My rule of thumb is three hours by the way. I'd like to say something
> like "not significantly slower than jenkins", but that's hard to
> quantify.
>

How do people normally throughput-optimize their CIs?

I suppose that parallelism is the basic trick, but how do people achieve
it? Concurrent tempest runs on the same host? or on a pool of (virtual)
hosts? or in one-shot disposable VMs?

The CI that I operate is currently running tests serially on a "bare metal"
server. This is okay for now (no backlog) but I would like to be able to
ramp up the number of tests performed and then performance could become an
issue.

The idea I'm playing with now is to support N servers each running M
parallel virtual machines for tempest. I'm tempted to use a disposable
Vagrant VM for each tempest run both in order to isolate tests from each
other (those running in parallel and also those that have run before) and
perhaps even make it possible for others (4th parties?) to grab my
Vagrantfile and replicate my test environment (if they want a faster
turn-around than via Gerrit).

I'd be very curious to know what is working well/badly for others at the
moment so that I can avoid stepping on land mines :-).

Cheers,
-Luke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140703/79e971b0/attachment.html>