[OpenAFS-devel] Testing (and a call for volunteers)

[Troy Benjegerdes]

If you are better at Git than I am, please go steal my changes from:

https://bitbucket.org/dahozer/tfs/changeset/ff224a236535f041d066c6c5ccfbc890b44b70e7

and make a proper Gerrit commit (see http://gerrit.openafs.org/#change,6843 )

On Sun, Sep 16, 2012 at 10:14:48AM -0400, Jason Edgecombe wrote:
> On 09/16/2012 05:11 AM, 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!
> 
> Simon,
> 
> I'm interested. How do I start? I was looking into the tests and
> "make check" fails with the error:
> 
> libtool: link: cannot find the library
> `/home/jwedgeco/openafs/openafs-git/openafs/src/opr/liboafs_util.la'
> or unhandled argument
> `/home/jwedgeco/openafs/openafs-git/openafs/src/opr/liboafs_util.la'
> make[2]: *** [vos-t] Error 1
> make[2]: Leaving directory
> `/home/jwedgeco/openafs/openafs-git/openafs/tests/volser'
> make[1]: *** [check] Error 1
> make[1]: Leaving directory
> `/home/jwedgeco/openafs/openafs-git/openafs/tests'
> make: *** [check] Error 2
> 
> 
> Thanks,
> Jason
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel