Hi guys.
While talking to DynWind on #gluster last night I raised an idea I've
been having about a testing xlator - after the chat I was asked to
present the idea to the list.... here are my ramblings :)
1) An option in the trace xlator for "option save-replay-file". When
this option is set, every action (and possibly the length of time
between each action) is recorded to the sepcified file in a machine
parsable format.
Why is this useful........
2) A replay xlator. This xlator takes the log file, and replays the
actions (at the specified time dealy possibly) to the subvolume.
I have been thinking about improving my own testing proceedures lately,
and was thinking about this way of testing in the glusterfs project. It
fits quite nicly with the xlator style.
I believe these log files can also be distributed with the source (with
permission from the originator anyway, in case of sensitive data). This
will ensure that each release of glusterfs will work in a specific
instance of calls. One could write the replay xlator to replay a bunch
of files (say, all the trace files in the testing directory) and report
on their success or failure.
I admit there should me more thought put into it, but it might be enough
to throw around some ideas.
One idea might be to have a dummy xlator as well, which can pretend to
have access to a file, or directory, and report the success of a file
open (when in fact no file actually exists). This could help when a
client produces a trace file to be replayed by the developers but no
such file exists on the developers system. Maybe it will use a listing
of valid files or somthing. But now I really am just rambling :)
Matt.
