Am Dienstag, den 28.05.2013, 07:49 -0600 schrieb Tim Flink:
- do some investigation to be somewhat sure that we're not
ignoring
existing tools (autotest is first on my list, beaker is
probably
worth exploring a bit)
This comparison will not be easy, the tools are large with lots of
features. It might be beneficial to include their developers (e.g.
lmr from autotest) in the discussions what we need and what the
tools
can offer. We have a lot of experience with autotest, but I somewhat
expect that there are many more features that we haven't even tried
to discover.
Yeah, I have no illusions that the comparison will be straight
forward.
The systems have very little in common outside of being written in
python and the fact that from a high level, they both execute jobs. I
suspect that a lot of it is going to come down to how much we want
flexibility.
Autotest is by far more featureful than buildbot from a test execution
perspective - it already has a test running system, it already has
concepts of more complicated results and supports jobs on remote and
multiple remote systems (probably more, those are the ones that come
to
mind right away). At the moment, I think buildbot is a better fit for
the idea of a loosely coupled system of components joined by json and
rest but creating such a system will likely require more initial work
to fill some gaps in functionality.
Hey,
I'm Fabian and writing to this list for the first time! I'm currently
working on oVirt (Node) (sub-)project which is a slimmed down Fedora (or
CentOS). Part of my $dayjob is to bring some test automation to oVirt
Node.
After this short introduction let me drop my two words. First I'd say
that the clean separation between the different actors is future proof.
I also agree on the roles of actors themselves and how they interact.
But as said elsewhere - the devil is in the details.
Now the last paragraph and tools.
In the oVirt Node we are using gerrit, jenkins and igor [0]. Igor is the
component which picks up an ISO and assigns it to some machine (real or
virtual, freshly created or existing one). Igor is then offering a
testsuite to client which can pull it and performing a number of
steps (testcases) on the host and reports them back to Igor. That's
the basic procedure [1]. Igor was designed to work in par with Jenkins,
that means - like in your idea - it is designed to push the results of
the runs to some remote result-bin.
I'm just mentioning Igor here because I believe that it solves some of
the problems that you'll be facing (in particular setting up and
preparing a real machine and running a number of steps on it) - so -
IIUIC - best matching the role of an Executor.
But I suppose a new thread - as you suggested - is the best place to
discuss the tools.
Greetings
fabian
[0] https://gitorious.org/ovirt/igord
[1]
http://dummdida.tumblr.com/post/51492048387/testing-ovirt-node-in-4min-video
___
qa-devel mailing list
qa-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/qa-devel
