[Gluster-devel] Translator test harness
avati at gluster.org
Tue Nov 19 04:32:52 UTC 2013
On Mon, Nov 18, 2013 at 8:23 PM, Shyamsundar Ranganathan <
srangana at redhat.com> wrote:
> ----- Original Message -----
> > From: "Jeff Darcy" <jdarcy at redhat.com>
> > To: "gluster-dev >> Gluster Devel" <gluster-devel at nongnu.org>
> > Sent: Monday, November 18, 2013 8:04:27 PM
> > Subject: [Gluster-devel] Translator test harness
> > Last week, Luis and I had a discussion about unit testing translator
> > code. Unfortunately, the structure of a translator - a plugin with many
> > entry points which interact in complex and instance-specific ways - is
> > one that is notoriously challenging. Really, the only way to do it is
> > to have some sort of a task-specific harness, with at least the
> > following parts:
> > * Code above to inject requests.
> > * Code below to provide mocked replies to the translator's own requests.
> > * Code "on the side" to track things like resources or locks acquired
> > and released.
> Interesting. KP (Krishnan P) and myself were discussing about an fault
> injection translator, (beyond error injection (which exists in the code
> base)), and were trying to narrow down some faults that we could inject to
> check and see if it makes sense to add such a translator.
> > This would be an ambitious undertaking, but not so ambitious that it's
> > beyond reason. The benefits should be obvious. At this point, what I'm
> > most interested in is volunteers to help define the requirements and
> > scope so that we can propose this as a feature or task for some future
> > GlusterFS release. Who's up for it?
> I would be interested in pitching in on this, and also hearing about
> extending this effort to cover fault injections if it makes sense.
It might be interesting to build a test harness using libgfapi (specially
the handle based APIs) to load a graph with the xlator to be test (on top
of posix) and using gfapi calls to bombard fops and notifications and
callbacks from multiple threads spawned by the testing app/framework.
Along with a fault injection, we also need a "pedantic verifier" translator
(loaded both on top and blow the testing xlator) which inspects all params
of all calls and callbacks coming out of the xlator to "conform" by the
rules (e.g lookup_cbk op_ret is either -1 or 0 ONLY, op_errno is one of the
known standard values ONLY, struct stat does not have mtime/ctime/atime
from too far ahead into the future, mkdir_cbk's struct stat has ia_type to
be IA_IFDIR ONLY etc.)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gluster-devel