cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rene Moser <>
Subject Re: Meet BlueOrangutan
Date Sun, 07 Aug 2016 09:40:53 GMT
Hi Rohit

On 08/06/2016 11:14 AM, Rohit Yadav wrote:

> Meet blueorangutan [1], a Github bot account that will help us automate CloudStack (PR)
testing [2][3] among other things.

Pretty cool. I like this progress. Well done!

> It works by polling Github notifications for the apache/cloudstack repository every minutes
and then reacts to comments. We can post comments on a apache/cloudstack PR and ask @blueorangutan
to perform certain build jobs such as building packages, then running Trillian [2] tests (across
a set of hypervisors) using those packages, and finally report us the results.
> Since, the task of building packages and testing them are expensive. A typical packaging
job may take up to 30 minutes, a typical Trillian [2][3] environment can take about 30 minutes
to build/deploy a zone, and a Trillian (smoke) test run may take hours while an exhaustive
Trillian (component+smoke) test run may take 3-4 days. Due to these reasons, for now the '@blueorangutan
test' task is restricted to a selected Github users (my colleagues at ShapeBlue). Running
Trillian test for each PR may be expensive, we may consider batching smaller thoroughly reviewed
PRs, then create packages for a set of PRs and test them all at once as well.

You mentioned "expensive", are there any plans to distribute the
workloads across whoever likes to provide some workload capacity?

Since trillian works on top of cloudstack and vmware, the only
requirement would be a similar environment and providing user account
access, right?

However to make it even more flexible, I would prefer a jenkins
master/slaves setup, in which you would configure slaves like fully
working trillian workers in the local environments.

Thinking a bit further how to make it as easy as possible for users, a
docker image containing the setup of jenkins having the job configured
and all necessary dependencies (ansible, cs, cloudmonkey) independend of
the docker host OS would be an option.

Any thoughts?


View raw message