saving state

Makefile.am

@@ -34,7 +34,7 @@ SPEC			= $(PACKAGE_NAME).spec
 TARFILE			= $(PACKAGE_NAME)-$(VERSION).tar.gz
 
 EXTRA_DIST		= autogen.sh conf/booth.conf.example \
-			  script/booth-keygen script/lsb script/ocf script/service-runnable.in \
+			  script/booth-keygen script/lsb script/ocf script/service-runnable.in script/crmv1.in \
 			  script/unit-test.py.in script/wireshark-dissector.lua \
 			  test/arbtests.py test/assertions.py test/booth_path test/boothrunner.py \
 			  test/boothtestenv.py.in test/clientenv.py test/clienttests.py test/live_test.sh \

README.crmv1

@@ -0,0 +1,49 @@
+CRMv1 cluster
+=============
+
+Heartbeat is a predecessor to Pacemaker and here we make a
+comeback to that kind of clustering. Why should we do that?
+Firstly, Pacemaker became a behemoth, something that can brew
+your coffee, but also something that is rather unwieldy and
+difficult to manage. Secondly, booth is a very reliable
+distributed engine and in our testing it was used also in a
+typical LAN and passed all the tests with flying colours. So,
+this is something for people who don't need all the bells and
+whistles of Pacemaker, but still want to have HA.
+
+STONITH is missing, but the cluster must have at least three
+members. Hence, the booth arbitrator serves as a fencing
+replacement. This is as it should be: a two node cluster is
+indeed very difficult to run. The booth arbitrator can be a
+smallish instance running wherever in your network. As with
+fencing, it doesn't even have to be particularly reliable, it
+just have to be there when we need it.
+
+Setup
+-----
+
+Just like with heartbeat, CRMv1 in booth is very simple to setup.
+There is a helper program called `crmv1` which is going to handle
+all the details. In the simplest setup, which is anyway the most
+common, there is just one group. The resources are run in order,
+there is no parallelism.
+
+Here the usage with one realistic example:
+
+	Usage: crmv1 {group <groupname> <rsc> ...|group delete <groupname>}
+
+	Examples:
+
+		crmv1 group bigdb \
+			IPaddr ip=192.168.1.1 \
+			ocf:linbit:drbd drbd_resource=bigdisk \
+			Filesystem device=/dev/bigdisk directory=/bigdisk fstype=xfs \
+			oracle sid=bigdb
+
+		crmv1 group delete bigdb
+
+There is no monitoring of resources, but it is easy to run an
+external monitor of the topmost resource, i.e. the service which
+is actually used by the users. If that monitor fails, then it
+makes sense to move the group to the other node.
+

conf/booth.conf.example

@@ -25,3 +25,7 @@ ticket="ticketA"
 ticket="ticketB"
 	expire = 600
 	weights = 1,2,3
+
+# Use the CRMv1 feature, i.e. make the booth a cluster in its own
+# right (run resource, etc)
+crmv1

conf/crmv1.conf.example

@@ -0,0 +1,15 @@
+# The crmv1 configuration file is "/etc/booth/crmv1/conf". You need to
+# prepare the same configuration file on each arbitrator and
+# each node in the cluster sites where the booth daemon can be launched.
+
+# The configuration consists of groups definition with parameters for resources
+# It is recommended to use the crmv1 program to prepare this
+# configuration file.
+# Here is one example:
+
+group bigdb \
+	IPaddr ip=192.168.1.1 \
+	ocf:linbit:drbd drbd_resource=bigdisk \
+	Filesystem device=/dev/bigdisk directory=/bigdisk fstype=xfs \
+	oracle sid=bigdb
+

script/crmv1

@@ -0,0 +1,116 @@
+#!/bin/bash
+#
+# This is crmv1, a tool to configure booth as a crmv1 style
+# cluster.
+# It basically manages groups. There is no concept of a group in
+# booth, but we can get by by using the before-acquire-handler.
+# Essentially, the handler is used to run programs (resource
+# agents). Just how the resource agents are configured is another
+# matter.
+#
+
+CONF_DIR=/etc/booth
+
+cnt=0
+
+usage() {
+	cat<<EOF >&2
+
+Usage: $0 {group <groupname> <ra> ...|group delete <groupname>}
+
+Examples:
+
+	crmv1 group bigdb \\
+		IPaddr ip=192.168.1.1 \\
+		ocf:linbit:drbd drbd_resource=bigdisk \\
+		Filesystem device=/dev/bigdisk directory=/bigdisk fstype=xfs \\
+		oracle sid=bigdb
+
+	crmv1 group delete bigdb
+
+EOF
+	exit $1
+}
+fatal() {
+	cat<<EOF >&2
+
+FATAL: $*
+
+EOF
+	exit 1
+}
+
+add_group() {
+	mkdir -p $CONF_DIR/crmv1/$2
+	echo "$@" >> $CONF_DIR/crmv1/conf
+}
+
+del_group() {
+	rm -rf $CONF_DIR/crmv1/$1
+	sed -i "/group $1/d" $CONF_DIR/crmv1/conf
+}
+
+get_ra() {
+	local ra
+	ra=$1
+	set `echo $ra | sed 's/:/ /g'`
+	if [ $# -eq 1 ]; then
+		dir=/usr/lib/ocf/resource.d/heartbeat
+	else
+		# 1:2:3
+		dir=/usr/lib/ocf/resource.d/$1/$2
+		ra=$3
+	fi
+	if [ -f $dir/$ra ]; then
+		echo $dir/$ra
+	else
+		fatal "no resource agent $1, did you install resource-agents?"
+	fi
+}
+
+mk_link() {
+	ln -fs $2 $CONF_DIR/crmv1/$1/`printf '%02d' $3`_`basename $2`
+}
+ln_ra() {
+	ra_f=`get_ra $2`
+	mk_link $1 $ra_f $cnt
+	cnt=$((cnt+1))
+}
+
+# this is not really creating a group, we just parse the input to
+# make sure that the group is well defined; the group is then
+# created by boothd on starting; consider this a document on how
+# creating a group should be implemented
+new_group() {
+	group=$2
+	shift 2
+	for p; do
+		save_ra=$p
+		if echo $p | grep -qs '='; then
+			args="$args $p"
+		else
+			if [ "$save_ra" ]; then
+				ln_ra $group $save_ra
+				save_ra=''
+				continue
+			fi
+		fi
+		ln_ra $group $p
+	done
+	add_group group $group $@
+}
+
+if [ $# -lt 3 ]; then
+	usage 1
+fi
+if [ $1 != group ]; then
+	usage 1
+fi
+if [ $2 != delete ]; then
+	if grep -qs "^group $2" $CONF_DIR/crmv1/conf; then
+		fatal "group $2 already exists"
+	fi
+	new_group $@
+else
+	del_group $3
+fi

src/booth.h

@@ -38,6 +38,7 @@
 #define BOOTH_DEFAULT_CONF_EXT ".conf"
 #define BOOTH_DEFAULT_CONF \
 	BOOTH_DEFAULT_CONF_DIR BOOTH_DEFAULT_CONF_NAME BOOTH_DEFAULT_CONF_EXT
+#define BOOTH_DEFAULT_CRMV1_CONF BOOTH_DEFAULT_CONF_DIR "crmv1/conf"
 
 #define DAEMON_NAME		"boothd"
 #define BOOTH_PATH_LEN		PATH_MAX
@@ -380,7 +381,4 @@ extern struct command_line cl;
 	 _a > _b ? _a : _b; })
 
 
-
-
-
 #endif /* _BOOTH_H */