>> If any of those tests fails (with some built in fault tolerance for a >> small >> hardware fallout rate), we stop the testing. All of that control flow >> is governed by a control file. It sounds complex, but it's really not >> if you build your "building blocks" carefully, and it's extremely powerful > > +1 > > The highly flexible config file currently serves client mode tests. > We need to slowly shift functionality into the server while keeping the > current advantages and simplicity of the client. > > Martin, can you give some links to the above meta control? The control files themselves aren't published external to google, but nearly all of the logic they use is - in server/frontend.py. I really need to refactor that file, it has both flow logic in it, and the basics for how to submit jobs to the frontend. The basic idea is to create pairings of (test, machine label), then kick off a job to all machines within that pairing and poll for the result. We typically use 3 to 5 of each machine type (platform) - if more than one of any platform fails, we call that a failure. The main entry point is run_test_suites(), which takes a list of such pairings, along with a kernel to test, etc. We will probably need do some work to generalize it, but the concept is all there, and it works well for us. >> Are all of your tests exclusive to KVM? I would think you'd want to be >> able to run any "normal" test inside a KVM environment too? > > There are several autotest tests that run inside the guest today too. > Today the config file controls their execution. It would be nice if we'll > create dependency using the server tests, that first installs VM, boot it > and then runs various 'normal' tests inside of it. I'm assuming you want to be able to both run tests inside the guests and on the raw host itself, at the same time? To that end, what we've planned to do (but not completed yet) is to merge the client and server code - so you can have autotest running on the scheduler, kicking off jobs to the host. That host can then autonomously control it's own guests, creating and destroying them, and kicking off tests inside of it. -- 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
