Resource Type: pacemaker_resource

Defined in:
lib/puppet/type/pacemaker_resource.rb
Providers:
xml
noop

Overview

Type for manipulating Corosync/Pacemaker primitives. Primitives are probably the most important building block when creating highly available clusters using Corosync and Pacemaker. Each primitive defines an application, ip address, or similar to monitor and maintain. These managed primitives are maintained using what is called a resource agent. These resource agents have a concept of class, type, and subsystem that provides the functionality. Regretibly these pieces of vocabulary clash with those used in Puppet so to overcome the name clashing the property and parameter names have been qualified a bit for clarity.

More information on primitive definitions can be found at the following link:

Properties

  • complex_metadata

    A hash of metadata for the complex primitives

  • complex_type (defaults to: simple)

    Which complex type this resource should be? Supported: clone, master, simple. The “simple” is the default value and means a non-complex resource.

    Supported values:
    • clone
    • master
    • simple
  • ensure (defaults to: present)

    The basic property that the resource should be in.

    Supported values:
    • present
    • absent
  • metadata

    A hash of metadata for the primitive. A primitive can have a set of metadata that doesn’t affect the underlying Corosync type/provider but affect that concept of a resource. This metadata is similar to Puppet’s resources resource and some meta-parameters, they change resource behavior but have no affect of the data that is synced or manipulated.

  • operations

    A hash of operations for the primitive. Operations defined in a primitive are little more predictable as they are commonly things like monitor or start and their values are in seconds. Since each resource agent can define its own set of operations we are going to defer again and just accept a hash. There maybe room to model this one but it would require a review of all resource agents to see if each operation is valid.

  • parameters

    A hash of params for the primitive. Parameters in a primitive are used by the underlying resource agent, each class using them slightly differently. In ocf scripts they are exported and pulled into the script as variables to be used. Since the list of these parameters are completely arbitrary and validity not enforced we simply defer defining a model and just accept a hash.

  • primitive_class

    Corosync class of the primitive. Examples of classes are lsb or ocf. Lsb funtions a lot like the init provider in Puppet for services, an init script is ran periodically on each host to identify status, or to start and stop a particular application. Ocf of the other hand is a script with meta-data and stucture that is specific to Corosync and Pacemaker.

  • primitive_provider

    Corosync primitive provider. All resource agents used in a primitve have something that provides them to the system, be it the Pacemaker or redhat plugins… they’re not always obvious though so currently you’re left to understand Corosync enough to figure it out. Usually, if it isn’t obvious it is because there is only one provider for the resource agent.

    To find the list of providers for a resource agent run the following from the command line has Corosync installed:

    • ‘crm configure ra providers <ra> <class>`

    Required for OCF primitives and may not be needed for other classes.

  • primitive_type

    Corosync primitive type. Type generally matches to the specific ‘thing’ your managing, i.e. ip address or vhost. Though, they can be completely arbitrarily named and manage any number of underlying applications or resources.

Parameters

  • debug (defaults to: false)

    Don’t actually make changes

    Supported values:
    • true
    • false
    • yes
    • no
  • name (namevar)

    Name identifier of primitive. This value needs to be unique across the entire Corosync/Pacemaker configuration since it doesn’t have the concept of name spaces per type.

  • provider

    The specific backend to use for this ‘pacemaker_resource` resource. You will seldom need to specify this — Puppet will usually discover the appropriate provider for your platform.