Forge Home


Puppet module for Corosync with Pacemaker setup and management.


10,348 latest version

3.8 quality score

We run a couple of automated
scans to help you access a
module's quality. Each module is
given a score based on how well
the author has formatted their
code and documentation and
modules are also checked for
malware using VirusTotal.

Please note, the information below
is for guidance only and neither of
these methods should be considered
an endorsement by Puppet.

Version information

  • 0.0.2 (latest)
  • 0.0.1
released Sep 3rd 2013

Start using this module

  • r10k or Code Manager
  • Bolt
  • Manual installation
  • Direct download

Add this module to your Puppetfile:

mod 'zooz-pacemaker', '0.0.2'
Learn more about managing modules with a Puppetfile

Add this module to your Bolt project:

bolt module add zooz-pacemaker
Learn more about using this module with an existing project

Manually install this module globally with Puppet module tool:

puppet module install zooz-pacemaker --version 0.0.2

Direct download is not typically how you would use a Puppet module to manage your infrastructure, but you may want to download the module in order to inspect the code.



zooz/pacemaker — version 0.0.2 Sep 3rd 2013


This module sets up a corosync with pacemaker service. It allows you to manage pacemaker resources, ordering constraints and cluster nodes.

It is highly recommended to read through pacemaker and corosync documentation first. This module abstracts the crm, cibadmin and cib_verify cli tools. It generates cib xml file from specified hashes, does cib verification and if that passes, then it applies the configuration to the cluster.

You have to dedicate a single node which will apply CIB configuration to the cluster. See manage_cib parameter below.

This module is most flexible and most easier to manage when used with hiera.




  • package - used to specify what version of the package should be used. Valid values: installed, absent or specific package version. Default: installed. Note: Puppet cannot downgrade packages.

  • service - service state. Valid values: running or stopped. Default: running.

  • onboot - whether to enable or disable the service on boot. Valid values: true, false or manual. Default: true.

  • manage_cib - if this is set to true, then the node which it is set on will manage CIB configuration. Default: false.

  • service_delay - Number of seconds for the corosync service to be delayed to start. This is useful when you have LACP bonded network interfaces, because they usually take around a minute to come up and start sending traffic. Default: 0.

  • bindnetaddr - This specifies the network address the corosync executive should bind to. bindnetaddr should be an IP address configured on the system, or a network address. For example, if the local interface is with netmask, you should set bindnetaddr to or If the local interface is with netmask, set bindnetaddr to or, and so forth. It must be specified, otherwise puppet run will fail.

  • mcastaddr - This is the multicast address used by corosync executive. The default should work for most networks, but the network administrator should be queried about a multicast address to use. Avoid 224.x.x.x because this is a "config" multicast address. It must be specified, otherwise puppet run will fail.

  • mcastport - This specifies the UDP port number. It is possible to use the same multicast address on a network with the corosync services configured for different UDP ports. Please note corosync uses two UDP ports mcastport (for mcast receives) and mcastport - 1 (for mcast sends). If you have multiple clusters on the same network using the same mcastaddr please configure the mcastports with a gap. Default: 5410.

  • debug_logging - This specifies whether debug output is logged for this particular logger. Also can contain value trace, what is highest level of debug informations. Default: off.

  • crm_config - It's a hash. It's generated from a set of hashes which specify crm_config parameters. See official documentation for valid parameters and their values. See examples below for the syntax.

  • nodes - Takes a list of node hostnames. Depending on your DNS and hostname settings, but preferably you should use hostname --short names here. It must be specified, otherwise puppet run will fail.

  • resources - It's a hash of hashes. Each hash defines a resource in pacemaker xml config. Valid hash keys are the following:

    • agent - which agent manages this resource, i.e. ocf:heartbeat:IPaddr2.
    • params - a hash of valid agent parameters.
    • operations - a hash of valid agent operations.
    • clone - whether to clone this resource or not. Valid values: true or false.
    • clone_params - valid cloned resource parameters.
  • constraints - It's a hash of hashes. Currently only order constraint is supported, but it's very easy to extend this module to support other constraint types. Valid hash keys:

    • type - type of a constraint. order is the only supported one right now.
    • first - which resource comes first, i.e. nginx:start
    • then - which resource comes next, i.e.ip200:start


  - pacemaker


  'no-quorum-policy': 'ignore'
  'stonith-enabled': 'false'
  'cluster-infrastructure': 'openais'

  - 'node0'
  - 'node1'
  - 'node2'

    agent: 'ocf:heartbeat:IPaddr2'
      cidr_netmask: 32
        interval: 60s
    agent: 'ocf:heartbeat:IPaddr2'
      cidr_netmask: 32
        interval: 60s
    agent: 'ocf:heartbeat:nginx'
        interval: 10s
    clone: true
      'clone-max': 2

    type: order
    first: 'nginx_clone:start'
    then: 'ip201:start'


  • Needs better validation of hash parameters.
  • Changes will only be made if cib_config.xml changes, which means, that if you make a change manually to the cluster configuration it will not be corrected until the next time you make a change by changing one of the hashes.
  • Supports Debian based distros only.