What about launching a couple of VM's using kvm/qemu? (this is where I'm going at the moment)
I'd also like to see a wiki, or some other documentation that attempts to capture some of the multi-node failure cases, and some sort of error injection test harness, so I can start thinking about how to recreate the failure with a couple of VM's 'in the cloud'. On Sun, Sep 16, 2012 at 10:11:47AM +0100, Simon Wilkinson wrote: > There's been a lot said on the list lately on the subject of testing, but > very little technical information. I thought that it might be worth > summarising the current state of the OpenAFS test suite, and to provide some > suggestions for how people could help make it better. Writing tests is a > pretty simple way of contributing to the whole OpenAFS effort. > > The problem we've had, historically, is that there's a lot of configuration > information hard coded into OpenAFS servers. It was hard to start them up as > a user other than root, hard to run them on a non-standard port, and hard to > provide them with configuration files from places other than the default > location. This is now improving - YFS has paid for, and contributed, changes > to the vlserver and the ptserver which allow them to be run as any user, and > to use non-standard database and configuration file locations. This means > that it is now possible to exercise these servers through the automated suite. > > Also from YFS, there is a load of support code to make running, starting and > stopping these servers easier. This all lives in tests/common > > All of this means that it should be easy to start improving our test coverage > of both of these servers. If anyone has a few spare moments and wants to > improve our testing, adding a few more tests to either the vlserver and > ptserver suites would be a great place to start. > > Longer term, I hope to modify the fileserver and volserver so that we can run > these from the test suite as well. This is harder, because they have a large > number of preconfigured paths and assumptions that makes it tricky to launch > them from an arbitrary developers account and tree. However, once this is > done, we'll be able to launch a complete AFS cell as part of make check. > > Of course, none of this will cover the cases that Jeffrey and David have been > talking about. Many of the bugs that we encounter in production with AFS are > incredibly complex - they rely on timing or load issues that just can't be > simulated in a single machine environment. Other tests require particular > versions of clients and servers, or on servers being modified to exhibit > particular buggy behaviour. > > That said, improving make check has value, even if it just frees up resources > to concentrate on these trickier bugs. Even basic functionality tests in make > check help us ship better releases. > > If you are interested in writing some tests, feel free to ask me for more > information! > > Cheers, > > Simon > > _______________________________________________ > OpenAFS-devel mailing list > [email protected] > https://lists.openafs.org/mailman/listinfo/openafs-devel _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
