From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [RFC] KVM-Autotest: basic parallel test execution Date: Mon, 01 Jun 2009 11:02:36 +0300 Message-ID: <4A238B1C.4010501@redhat.com> References: <1294159996.47211242571742642.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com> <4A1068F2.9070706@redhat.com> <4A146666.3010505@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Michael Goldish , KVM List To: mburns@redhat.com Return-path: Received: from mx2.redhat.com ([66.187.237.31]:53911 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755346AbZFAICh (ORCPT ); Mon, 1 Jun 2009 04:02:37 -0400 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n5182diq008975 for ; Mon, 1 Jun 2009 04:02:39 -0400 In-Reply-To: <4A146666.3010505@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Mike Burns 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. > I'm an administrator of kvm-autotest and I have no idea how to create control and kvm_tests.cfg files. Also, I'm a lot more interested in spreading the load on my one host rather than on fictional other hosts. And for that we need a scheduler, since different tests need differing amounts of memory and cores. >>> - 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. > Host setups should be separated from test setup, so that tests can be continuously updated while the host setup is kept static. >> 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. > As a user, I disagree. I can't calculate what resources are needed by each test and make sure they all fit on my host. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.