Upstart support coming to Pacemaker

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 cluster-glue
cd cluster-glue
# Next step is important: must include --enable-upstart to enable upstart support
./configure --enable-upstart
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

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!

5 Responses to Upstart support coming to Pacemaker

  1. Alan Robertson says:

    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).

  2. dave williams says:

    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.

  3. dave williams says:

    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.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: