----- "Mike Burns" <mburns@xxxxxxxxxx> wrote:
> Avi Kivity wrote:
> > Michael Goldish wrote:
> >> Drawbacks:
> >> - requires some initial work to be done by the user -- the user
> has
> >> to define exactly where each test should run
> >>
> >
> > For me, this is a major drawback. I'd really like a
> fire-and-forget
> > solution. If I have to spend my own time getting this to work, vs.
> > waiting longer for the tests to run on their own, I'll just be
> lazy.
> It seems like this is adding another layer of user interaction
> without
> really getting that much additional functionality. An administrator
> of
> kvm-autotest is going to know enough to be able to create control and
> kvm_tests.cfg files that can mimic this already and then just create
> 2
> jobs in the server to run on different hosts.
> >
> >> - test sets need to be modified when tests or hosts are
> >> added/removed, to include/exclude them
> >>
> >
> > This is also annoying -- and likely to stop me from updating.
> Host definitions already happen on the server and it seems like it
> would
> be confusing to have to make sure that the host you choose when
> setting
> up a test is setup correctly in your config files.
> >
> >> We'd like to get some feedback on this -- is it usable,
> comfortable,
> >> do you have any suggestions, etc. We'll also be happy to answer
> >> questions.
> >> There are no actual patches attached to this message because the
> >> implementation is trivial and we want to focus on the user's point
> of
> >> view.
> >>
> >>
> >
> >
> > I'd really like this to be automated, just specify a set of
> machines
> > and have the jobs distributed. Furthermore, it is very important
> to
> > utilize the existing hosts better. A 4-core 4GB server can easily
> run
> > a 2x smp 1GB guest and 2 other uniprocessor 1GB guests. It's
> wasteful
> > to add more servers when the existing servers are underutilized.
> >
> Overall, the way I envisioned parallel test execution was having
> multiple tests running on a single machine. It seems that the server
> already provides most (if not all) the functionality needed to spread
> tests across multiple machines. I really think this is putting too
> much on the user for very small gains in functionality.
This suggestion does allow running multiple tests in parallel on a
single machine.
host1:
only queue1 queue2
means there will be 2 queues running in parallel on host1, and
queue1:
only Fedora
means queue1 will run Fedora tests (in parallel to whatever queue2 will
be running).
Other than that, the suggestion doesn't add much new functionality.
However, since it's backwards compatible, in the sense that regular
test sets (like fc8_quick) can still be defined the usual way alongside
the new test sets, the cost may not be that high. The user is required
to define hosts only if he/she intends to specify test sets in the new
format.
Backwards compatibility is achieved by defining a host variant 'anyhost'
with no hostname. Then we just need to add 'only anyhost' to our
fc8_quick, and it becomes compatible with the new format. We can also use
just client parallelization, by using multiple queues with anyhost, e.g.
fc8_quick:
only anyhost
only queue1 queue2 queue3
queue1:
only something
queue2:
only something_else
(this will run fc8_quick on all hosts, with multiple queues on each host.)
In other words, there may not be much new functionality, but it's nearly
'free'. Also, it is somewhat appealing that implementing this involves as
few as 1-2 extra lines of code (in addition to the kvm_hosts.cfg file),
because it relies on existing capabilities of the config file parser.
It's not that I'm lazy -- it's just that it leaves very little room for
mistakes to be made.
On the other hand, Lucas says the technical problems we've encountered
while experimenting with server control files are most likely bugs that
have been resolved recently, so maybe we should just go ahead and implement
fully automatic test dispatching from the server. That was the original
plan anyway.
I suggested the simpler option just to see if people happen to find it
appealing. So far this doesn't seem to be the case, so we might as well
skip it. Let me know if this message changes your mind though (from your
message I got the impression that you weren't aware that this suggestion
enables running multiple tests on a single machine).
Thanks,
Michael
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
