Thanks primarily to the efforts of Senko Rašić and Ante Karamatić, the Pacemaker cluster stack is being augmented with support for Upstart services. This is in addition to support for OCF resource agents and LSB/SysV init scripts, both of which have been supported in Pacemaker for years.
This is functionality now present in the upstream Mercurial trees, and we need testers to get in shape for release. Yes, that means you can help!
This is primarily relevant to you if you use a distribution with upstart as its default init daemon. This includes Ubuntu lucid, OpenSuSE 11.3, recent Fedora releases, and others. To enable upstart support, you will need an upstream hg tip for the cluster-glue libraries, and for Pacemaker.
Here’s how I build cluster-glue with upstart support from local hg checkouts:
hg clone http://hg.linux-ha.org/glue cluster-glue cd cluster-glue ./autogen.sh # Next step is important: must include --enable-upstart to enable upstart support ./configure --enable-upstart make sudo make install
… and then I simply continue like I normally would for a Pacemaker from-source install, as illustrated here.
When I’m done, and have configured my Heartbeat/Pacemaker cluster as shown here, I can proceed with adding an Upstart based job to my cluster configuration:
crm configure primitive mysql upstart:mysql \ op start timeout=120s op stop timeout=120s op monitor interval=30s commit
And that’s it! Now I can use the mysql upstart job like any other cluster resource. Try it out — and please report back any issues you encounter!
Florian's blog 
Good to hear about this. I recently thought about adding this, but it’s good to see someone has already added it (presumably to the LRM).
Yes, this was added to the LRM. Plus a trivial change to the Pacemaker schema to allow the
upstart:jobprimitive syntax.I presume the upstart scripts called need to be lsb compliant to be usable as resource agents. My system has converted vsftpd init.d script to an upstart job upon an upgrade but neither the original or the replacement are lsb compliant – eg. they always return an exist code of 0 even when the status says the daemon stopped. crm_mon complains about this when you look at why the cluster doesnt do what you expect when using either resource type.
Well, yes. Getting a proper response when querying the resource status is essentially a must.
Well depends what “proper response” means. init.d scripts returned response in exit codes. upstart returns them in a (loosely) formatted string. I didnt know if the new cluster glue effectively parses the formatted string or whether it needed some help.
I havent looked at the source code to find out how it works and was sort of hoping you might have delved into it in a bit more detail than I have so far. Its just I’m geting some warning messages saying exit codes of non zero were expected but 0 was received. It seems upstart always exits with 0.