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. -- 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
