Opened at 2008-01-04T19:35:57Z
Closed at 2008-06-01T02:58:16Z
#255 closed defect (fixed)
FUSE integration doesn't have automated tests
Reported by: | zooko | Owned by: | nejucomo |
---|---|---|---|
Priority: | major | Milestone: | eventually |
Component: | code-frontend | Version: | 0.7.0 |
Keywords: | fuse | Cc: | |
Launchpad Bug: |
Description
We just discovered that the FUSE extension that nejucomo had contributed had bit-rotted. This is what happens to software that doesn't have automated tests.
Nejucomo and I have chatted about it, and he says it is hard to make isolated tests for the Python FUSE library because the only way to use it is to subclass it, and you cannot instantiate your subclass without hooking into a running Linux kernel. :-)
Change History (5)
comment:1 Changed at 2008-01-05T05:21:35Z by warner
comment:2 Changed at 2008-01-06T05:20:27Z by zooko
- Owner changed from nejucomo to arch_o_median
comment:3 Changed at 2008-02-14T14:35:34Z by zooko
nejucomo has added some tests -- see the revision control log of the {{{contrib/fuse}}} directory.
nejucomo: would you please close this ticket and open a new one describing more specific tests that you want to add?
comment:4 Changed at 2008-02-14T14:36:18Z by zooko
- Owner changed from arch_o_median to nejucomo
comment:5 Changed at 2008-06-01T02:58:16Z by nejucomo
- Resolution set to fixed
- Status changed from new to closed
There are tests in the "runtests.py" script accompanying tahoe_fuse.py (fuse_a).
There is one trivial unit test that this script executes. Then it executes what I call "system tests" because they are not certainly deterministic, and involve launching processes, various race conditions, and other ugliness.
All this being said, they seem to work on my system. (They have bitrotted since introduced, and I'm close to submitting a patch which updates them for allmydata 1.0.0-r2528 and ubuntu python-fuse 1:0.2-pre3-3.)
Yeah, that will be fun :-). The way to do it is to run the buildslave on dedicated machine (perhaps a VM) that has a couple of setuid scripts that can run the mount/umount commands (maybe speak foolscap to a server running as root that will run those commands upon request). The builder then needs to do:
Of course, if we want to assert that the FUSE plugin will work against other Tahoe versions (not just HEAD), then it could use an existing tahoe node (running a known version) instead of updating and restarting a node each time. This probably won't be appropriate until Tahoe's HTTP API has stabilized a bit.