veyepar: Testing CTDB - not necessarily trivial

Author(s):	Martin Schwenke,Ronnie Sahlberg
Location	C001
Date	jan Wed 18	Days Raw Files
Start	13:20	First Raw Start	error-in-template
Duration	0:50:00	Offset	None
End	14:10	Last Raw End
Chapters
Total cuts_time	None min.

http://lca2012.linux.org.au/schedule/194/view_talk
raw-playlist raw-mp4-playlist encoded-files-playlist mp4 svg png

assets release.pdf Testing_CTDB_not_necessarily_trivial.json
logs
Admin: episode episode list cut list raw files day marks day marks day image_files

State:

Locked:

clear this to unlock

Locked by:

user/process that locked.

Start:

initially scheduled time from master, adjusted to match reality

Duration:

length in hh:mm:ss

Name:

Video Title (shows in video search results)

Emails:

email(s) of the presenter(s)

Released:

has someone authorised pubication

Normalise:

Channelcopy:

m=mono, 01=copy left to right, 10=right to left, 00=ignore.

Thumbnail:

filename.png

Description:

markdown

Presented by Martin Schwenke and Ronnie Sahlberg.

CTDB, the Clustered Trivial Database, is used to support clustered
versions of Samba, NFS, HTTP and other protocols.  It handles node
monitoring, network failover and synchronisation of state between
nodes.  As such, there are a lot of moving parts and automated testing
is non-trivial.

We present details of some testing techniques being used by CTDB.
Given that CTDB normally runs as root we have tried to find testing
methods that allow a developer to run "make test" as a regular user in
the development tree and do a useful amount of testing.  One unit
testing technique involves scripted stub replacements to replace
various system commands, allowing event scripts to be tested in a
sandbox.  We were going to build a shared library containing most of
the CTDB code and replace some functions with stubs using LD_PRELOAD,
allowing a useful subset of CTDB's functions to be unit tested.
Instead we decided to build CCAN-style test programs that "just"
#include all the relevant source code - this makes it easy to test
static functions.  For system testing, we also discuss our use of
KVM-based virtual clusters and our trivial configuration tool to make
it easier to setup such clusters.  The techniques probably aren't
original or mindblowing but should still be of interest to many
developers. :-)

Comment:

production notes