corosync

This module is a set of manifests and types/providers for quickly setting up highly available clusters using Corosync

Project URL RSS Feed Report issues

Module Stats

118,740 downloads

44,279 latest version

4.0 quality score

Version information

released Dec 2nd 2014

This module has been deprecated by its author since Mar 21st 2017.

The reason given was: Maintainership migrated to Vox Pupuli

The author has suggested puppet-corosync as its replacement.

Start using this module

Installation method

Add this module to your Puppetfile:

mod 'puppetlabs-corosync', '0.7.0'

Learn more about managing modules with a Puppetfile

Add this module to your Bolt project:

bolt module add puppetlabs-corosync

Learn more about using this module with an existing project

Manually install this module globally with Puppet module tool:

puppet module install puppetlabs-corosync --version 0.7.0

Tags: debian, ha, heartbeat, pacemaker

Documentation

puppetlabs/corosync — version 0.7.0 Dec 2nd 2014

Puppet Labs module for Corosync

Corosync is a cluster stack written as a reimplementation of all the core functionalities required by openais. Meant to provide 100% correct operation during failures or partitionable networks.

Most famous for being the cluster stack used by Pacemaker to support n-code clusters that can respond to node and resource level events.

Basic usage

To install and configure Corosync

class { 'corosync':
  enable_secauth    => true,
  authkey           => '/var/lib/puppet/ssl/certs/ca.pem',
  bind_address      => $ipaddress,
  multicast_address => '239.1.1.2',
}

To enable Pacemaker

corosync::service { 'pacemaker':
  version => '0',
}

Configuring primitives

The resources that Corosync will manage can be referred to as a primitive. These are things like virtual IPs or services like drbd, nginx, and apache.

To assign a VIP to a network interface to be used by Nginx

cs_primitive { 'nginx_vip':
  primitive_class => 'ocf',
  primitive_type  => 'IPaddr2',
  provided_by     => 'heartbeat',
  parameters      => { 'ip' => '172.16.210.100', 'cidr_netmask' => '24' },
  operations      => { 'monitor' => { 'interval' => '10s' } },
}

Make Corosync manage and monitor the state of Nginx using a custom OCF agent

cs_primitive { 'nginx_service':
  primitive_class => 'ocf',
  primitive_type  => 'nginx_fixed',
  provided_by     => 'pacemaker',
  operations      => {
    'monitor' => { 'interval' => '10s', 'timeout' => '30s' },
    'start'   => { 'interval' => '0', 'timeout' => '30s', 'on-fail' => 'restart' }
  },
  require         => Cs_primitive['nginx_vip'],
}

Make Corosync manage and monitor the state of Apache using a LSB agent

cs_primitive { 'nginx_service':
  primitive_class => 'lsb',
  primitive_type  => 'apache2',
  provided_by     => 'heartbeat',
  operations      => {
    'monitor' => { 'interval' => '10s', 'timeout' => '30s' },
    'start'   => { 'interval' => '0', 'timeout' => '30s', 'on-fail' => 'restart' }
  },
  require         => Cs_primitive['apache2_vip'],
}

Note: Operations with the same names should be declared as an Array. Example:

cs_primitive { 'pgsql_service':
  primitive_class => 'ocf',
  primitive_type  => 'pgsql',
  provided_by     => 'heartbeat',
  operations      => {
    'monitor' => [
      { 'interval' => '10s', 'timeout' => '30s' },
      { 'interval' => '5s', 'timeout' => '30s', 'role' => 'Master' },
    ],
    'start'   => { 'interval' => '0', 'timeout' => '30s', 'on-fail' => 'restart' }
  },
}

Configuring locations

Locations determine on which nodes primitive resources run.

cs_location { 'nginx_service_location':
  primitive => 'nginx_service',
  node_name => 'hostname',
  score     => 'INFINITY'
}

Configuring colocations

Colocations keep primitives together. Meaning if a vip moves to web02 from web01 because web01 just hit the dirt it will drag the nginx service with it.

cs_colocation { 'vip_with_service':
  primitives => [ 'nginx_vip', 'nginx_service' ],
}

Configuring migration or state order

Colocation defines that a set of primitives must live together on the same node but order definitions will define the order of which each primitive is started. If Nginx is configured to listen only on our vip we definitely want the vip to be migrated to a new node before nginx comes up or the migration will fail.

cs_order { 'vip_before_service':
  first   => 'nginx_vip',
  second  => 'nginx_service',
  require => Cs_colocation['vip_with_service'],
}

Corosync Properties

A few gloabal settings can be changed with the "cs_property" section.

Disable STONITH if required.

cs_property { 'stonith-enabled' :
  value   => 'false',
}

Change quorum policy

cs_property { 'no-quorum-policy' :
  value   => 'ignore',
}

Dependencies

Tested and built on Debian 6 using backports so version 1.4.2 of Corosync is validated to function.

Notes

This module doesn't abstract away everything about managing Corosync but makes setup and automation easier. Things that are currently outstanding...

Needs a lot more tests.
There is already a handful of bugs that need to be worked out.
Plus a other things since Corosync and Pacemaker do a lot.

We suggest you at least go read the Clusters from Scratch document from Cluster Labs. It will help you out a lot when understanding how all the pieces fall together a point you in the right direction when Corosync fails unexpectedly.

A simple but complete manifest example can be found on Cody Herriges' Github, plus there are more incomplete examples spread across the Puppet Labs Github.

Contributors

See Puppet Labs Github

Copyright and License

Puppet Labs can be contacted at: info@puppetlabs.com

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

Types in this module release

cs_location

Type for manipulating corosync/pacemaker resource location. More information on Corosync/Pacemaker colocation can be found here:

  * http://www.clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Clusters_from_Scratch/_ensuring_resources_run_on_the_same_host.html

Parameters
cib	Corosync applies its configuration immediately. Using a CIB allows you to group multiple primitives and relationships to be applied at once. This can be necessary to insert complex configurations into Corosync correctly. `This paramater sets the CIB this colocation should be created in. A cs_shadow resource with a title of the same name as this value should also be added to your manifest.`
ensure
name	Identifier of the location entry. 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

Properties
node_name	The corosync node_name where the resource should be located.
primitive	The corosync resource primitive to have a location applied.
score	The priority of this location. Primitives can be a part of multiple location groups and so there is a way to control which primitives get priority when forcing the move of other primitives. This value can be an integer but is often defined as the string INFINITY.

Providers
crm	Specific provider for a rather specific type since I currently have no plan to abstract corosync/pacemaker vs. keepalived. This provider will check the state of current primitive locations on the system; add, delete, or adjust various aspects.

cs_commit

Parameters
name
provider

cs_group

Type for manipulating Corosync/Pacemkaer group entries. Groups are a set or resources (primitives) that need to be grouped together.

  More information can be found at the following link:

  * http://www.clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Pacemaker_Explained/ch-advanced-resources.html#group-resources

Parameters
cib	Corosync applies its configuration immediately. Using a CIB allows you to group multiple primitives and relationships to be applied at once. This can be necessary to insert complex configurations into Corosync correctly. `This paramater sets the CIB this order should be created in. A cs_shadow resource with a title of the same name as this value should also be added to your manifest.`
ensure
name	Name identifier of this group entry. 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

Properties
primitives	An array of primitives to have in this group. Must be listed in the order that you wish them to start.

Providers
crm	Provider to add, delete, manipulate primitive groups.
pcs	Provider to add, delete, manipulate primitive groups.

cs_primitive

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:

  * http://www.clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Clusters_from_Scratch/_adding_a_resource.html

Parameters
cib	Corosync applies its configuration immediately. Using a CIB allows you to group multiple primitives and relationships to be applied at once. This can be necessary to insert complex configurations into Corosync correctly. `This paramater sets the CIB this primitive should be created in. A cs_shadow resource with a title of the same name as this value should also be added to your manifest.`
ensure
name	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.
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_type	Corosync primitive type. Type generally matches to the specific 'thing' your managing, i.e. ip address or vhost. Though, they can be completely arbitarily named and manage any number of underlying applications or resources.
provided_by	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>`
provider

Properties
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.
ms_metadata	A hash of metadata for the master/slave primitive state.
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.
promotable	Designates if the primitive is capable of being managed in a master/slave state. This will create a new ms resource in your Corosync config and add this primitive to it. Concequently Corosync will be helpful and update all your colocation and order resources too but Puppet won't. Currenlty we unmunge configuraiton entries that start with ms_ so that you don't have to account for name change in all our manifests.
utilization	A hash of utilization attributes for the primitive. If nodes are also configured with available resources, and Pacemaker's placement stratgey is set appropriately, then Pacemaker can place primitives on nodes only where resources are available. `See the Pacemaker documentation: http://clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Pacemaker_Explained/ch11.html`

Providers
crm	Specific provider for a rather specific type since I currently have no plan to abstract corosync/pacemaker vs. keepalived. Primitives in Corosync are the thing we desire to monitor; websites, ipaddresses, databases, etc, etc. Here we manage the creation and deletion of these primitives. We will accept a hash for what Corosync calls operations and parameters. A hash is used instead of constucting a better model since these values can be almost anything.
pcs	Specific provider for a rather specific type since I currently have no plan to abstract corosync/pacemaker vs. keepalived. Primitives in Corosync are the thing we desire to monitor; websites, ipaddresses, databases, etc, etc. Here we manage the creation and deletion of these primitives. We will accept a hash for what Corosync calls operations and parameters. A hash is used instead of constucting a better model since these values can be almost anything.

Providers

crm

Specific provider for a rather specific type since I currently have no plan to abstract corosync/pacemaker vs. keepalived. Primitives in Corosync are the thing we desire to monitor; websites, ipaddresses, databases, etc, etc. Here we manage the creation and deletion of these primitives. We will accept a hash for what Corosync calls operations and parameters. A hash is used instead of constucting a better model since these values can be almost anything.

pcs

cs_order

Type for manipulating Corosync/Pacemkaer ordering entries. Order entries are another type of constraint that can be put on sets of primitives but unlike colocation, order does matter. These designate the order at which you need specific primitives to come into a desired state before starting up a related primitive.

  More information can be found at the following link:

  * http://www.clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Clusters_from_Scratch/_controlling_resource_start_stop_ordering.html

Parameters
cib	Corosync applies its configuration immediately. Using a CIB allows you to group multiple primitives and relationships to be applied at once. This can be necessary to insert complex configurations into Corosync correctly. `This paramater sets the CIB this order should be created in. A cs_shadow resource with a title of the same name as this value should also be added to your manifest.`
ensure
name	Name identifier of this ordering entry. 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
resources_type	String to specify which HA resource type is used for this order, e.g. when you want to order groups (cs_group) instead of primitives. Defaults to cs_primitive.

Properties
first	First Corosync primitive. Just like colocation, our primitives for ording come in pairs but this time order matters so we need to define which primitive starts the desired state change chain.
score	The priority of the this ordered grouping. Primitives can be a part of multiple order groups and so there is a way to control which primitives get priority when forcing the order of state changes on other primitives. This value can be an integer but is often defined as the string INFINITY.
second	Second Corosync primitive. Our second primitive will move to the desired state after the first primitive.
symmetrical	Boolean specifying if the resources should stop in reverse order. Default value: true.

Providers
crm	Specific provider for a rather specific type since I currently have no plan to abstract corosync/pacemaker vs. keepalived. This provider will check the state of current primitive start orders on the system; add, delete, or adjust various aspects.
pcs	Specific provider for a rather specific type since I currently have no plan to abstract corosync/pacemaker vs. keepalived. This provider will check the state of current primitive start orders on the system; add, delete, or adjust various aspects.

cs_shadow

cs_shadow resources represent a Corosync shadow CIB. Any corosync resources defined with 'cib' set to the title of a cs_shadow resource will not become active until all other resources with the same cib value have also been applied.

Parameters
name	Name of the shadow CIB to create and manage
provider

Properties
cib

Providers
crm
pcs

cs_property

Type for manipulating corosync/pacemaker configuration properties. Besides the configuration file that is managed by the module the contains all these related Corosync types and providers, there is a set of cluster properties that can be set and saved inside the CIB (A CIB being a set of configuration that is synced across the cluster, it can be exported as XML for processing and backup). The type is pretty simple interface for setting key/value pairs or removing them completely. Removing them will result in them taking on their default value.

  More information on cluster properties can be found here:

  * http://www.clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Pacemaker_Explained/_cluster_options.html

  P.S Looked at generating a type dynamically from the cluster's property
  meta-data that would result in a single type with puppet type properties
  of every cluster property...may still do so in a later iteration.

Parameters
ensure
name	Name identifier of this property. Simply the name of the cluster property. Happily most of these are unique.
provider

Properties
value	Value of the property. It is expected that this will be a single value but we aren't validating string vs. integer vs. boolean because cluster properties can range the gambit.

Providers
crm	Specific provider for a rather specific type since I currently have no plan to abstract corosync/pacemaker vs. keepalived. This provider will check the state of Corosync cluster configuration properties.
pcs	Specific provider for a rather specific type since I currently have no plan to abstract corosync/pacemaker vs. keepalived. This provider will check the state of Corosync cluster configuration properties.

cs_colocation

Type for manipulating corosync/pacemaker colocation. Colocation is the grouping together of a set of primitives so that they travel together when one of them fails. For instance, if a web server vhost is colocated with a specific ip address and the web server software crashes, the ip address with migrate to the new host with the vhost.

  More information on Corosync/Pacemaker colocation can be found here:

  * http://www.clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Clusters_from_Scratch/_ensuring_resources_run_on_the_same_host.html

Parameters
cib	Corosync applies its configuration immediately. Using a CIB allows you to group multiple primitives and relationships to be applied at once. This can be necessary to insert complex configurations into Corosync correctly. `This paramater sets the CIB this colocation should be created in. A cs_shadow resource with a title of the same name as this value should also be added to your manifest.`
ensure
name	Identifier of the colocation entry. 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

Properties
primitives	Two Corosync primitives to be grouped together. Colocation groups come in twos and order is irrelavent. Property will raise an error if you do not provide a two value array.
score	The priority of this colocation. Primitives can be a part of multiple colocation groups and so there is a way to control which primitives get priority when forcing the move of other primitives. This value can be an integer but is often defined as the string INFINITY.

Providers
crm	Specific provider for a rather specific type since I currently have no plan to abstract corosync/pacemaker vs. keepalived. This provider will check the state of current primitive colocations on the system; add, delete, or adjust various aspects.
pcs	Specific provider for a rather specific type since I currently have no plan to abstract corosync/pacemaker vs. keepalived. This provider will check the state of current primitive colocations on the system; add, delete, or adjust various aspects.

##2014-12-2 - Release 0.7.0 ###Summary This release refactors the main class to use corosync::params for defaults and no longer checks global variables for the parameters. It also includes strict variable support, a few other features, and a bugfix for EL platforms.

####Backwards Incompatible Changes Class corosync no longer uses global varaibles $::port, $::threads, $::port, $::bind_address, $::unicast_addresses, $::multicast_address, or $::enable_secauth. These should be passed as parameters to the corosync class instead.

####Features

Strict variable support
Add support for spaces in cs_primitive parameters
Add support for multiple operations with the same name
Add some parameter validation

####Bugfixes

Removed enable corosync exec for EL platforms

##2014-07-15 - Release 0.6.0 ###Summary

This release adds support for the PCS provider. It also updates metadata.json so the module can be uninstalled and upgraded via the puppet module command.

####Features

Add support for PCS provider

##2014-06-24 - Release 0.5.0 ###Summary

This module has undergone two years of development, and pretty much every aspect of it has changed in some regard. I've tried to capture the key changes below, but you should rely on the README to see how things work now.

####Features

Added a new resource type cs_location.
Make primitive utilization attributes managable.
Added symmetrical parameter on cs_order (for ordering).
Allow ordering of cs_groups.
Allow to specify rrpmode and ttl.
Allow to specifiy several rings.
Permit broadcast.
Allow more than two primitives per cs_colocation.
Allow the authkey to be provided as a string.
Add tests.
Rework significant amounts of the provider code.

####Bugfixes

Delete an existing cib to start fresh
Only change /etc/defaults for corosync startup on Debian platforms
Fix templates for Puppet 3.2+.
Don't complain if cs_primitive doesn't have a utilization parameter.
Consider <instance_attributes/> within primitive operations.
Changed osfamily check to include other operating systems.
Updated node to node_name in cs_location function as 'node' is a reserved name, this replacement allows cs_location to work correctly.

##2012-10-14 - Release 0.1.0

Added robustness for general corosync management (read the merges)
Added cs_group type
Added some testing
Generally tried to get on top of this thing.

                                 Apache License
                           Version 2.0, January 2004
                        http://www.apache.org/licenses/

   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION

   1. Definitions.

      "License" shall mean the terms and conditions for use, reproduction,
      and distribution as defined by Sections 1 through 9 of this document.

      "Licensor" shall mean the copyright owner or entity authorized by
      the copyright owner that is granting the License.

      "Legal Entity" shall mean the union of the acting entity and all
      other entities that control, are controlled by, or are under common
      control with that entity. For the purposes of this definition,
      "control" means (i) the power, direct or indirect, to cause the
      direction or management of such entity, whether by contract or
      otherwise, or (ii) ownership of fifty percent (50%) or more of the
      outstanding shares, or (iii) beneficial ownership of such entity.

      "You" (or "Your") shall mean an individual or Legal Entity
      exercising permissions granted by this License.

      "Source" form shall mean the preferred form for making modifications,
      including but not limited to software source code, documentation
      source, and configuration files.

      "Object" form shall mean any form resulting from mechanical
      transformation or translation of a Source form, including but
      not limited to compiled object code, generated documentation,
      and conversions to other media types.

      "Work" shall mean the work of authorship, whether in Source or
      Object form, made available under the License, as indicated by a
      copyright notice that is included in or attached to the work
      (an example is provided in the Appendix below).

      "Derivative Works" shall mean any work, whether in Source or Object
      form, that is based on (or derived from) the Work and for which the
      editorial revisions, annotations, elaborations, or other modifications
      represent, as a whole, an original work of authorship. For the purposes
      of this License, Derivative Works shall not include works that remain
      separable from, or merely link (or bind by name) to the interfaces of,
      the Work and Derivative Works thereof.

      "Contribution" shall mean any work of authorship, including
      the original version of the Work and any modifications or additions
      to that Work or Derivative Works thereof, that is intentionally
      submitted to Licensor for inclusion in the Work by the copyright owner
      or by an individual or Legal Entity authorized to submit on behalf of
      the copyright owner. For the purposes of this definition, "submitted"
      means any form of electronic, verbal, or written communication sent
      to the Licensor or its representatives, including but not limited to
      communication on electronic mailing lists, source code control systems,
      and issue tracking systems that are managed by, or on behalf of, the
      Licensor for the purpose of discussing and improving the Work, but
      excluding communication that is conspicuously marked or otherwise
      designated in writing by the copyright owner as "Not a Contribution."

      "Contributor" shall mean Licensor and any individual or Legal Entity
      on behalf of whom a Contribution has been received by Licensor and
      subsequently incorporated within the Work.

   2. Grant of Copyright License. Subject to the terms and conditions of
      this License, each Contributor hereby grants to You a perpetual,
      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
      copyright license to reproduce, prepare Derivative Works of,
      publicly display, publicly perform, sublicense, and distribute the
      Work and such Derivative Works in Source or Object form.

   3. Grant of Patent License. Subject to the terms and conditions of
      this License, each Contributor hereby grants to You a perpetual,
      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
      (except as stated in this section) patent license to make, have made,
      use, offer to sell, sell, import, and otherwise transfer the Work,
      where such license applies only to those patent claims licensable
      by such Contributor that are necessarily infringed by their
      Contribution(s) alone or by combination of their Contribution(s)
      with the Work to which such Contribution(s) was submitted. If You
      institute patent litigation against any entity (including a
      cross-claim or counterclaim in a lawsuit) alleging that the Work
      or a Contribution incorporated within the Work constitutes direct
      or contributory patent infringement, then any patent licenses
      granted to You under this License for that Work shall terminate
      as of the date such litigation is filed.

   4. Redistribution. You may reproduce and distribute copies of the
      Work or Derivative Works thereof in any medium, with or without
      modifications, and in Source or Object form, provided that You
      meet the following conditions:

      (a) You must give any other recipients of the Work or
          Derivative Works a copy of this License; and

      (b) You must cause any modified files to carry prominent notices
          stating that You changed the files; and

      (c) You must retain, in the Source form of any Derivative Works
          that You distribute, all copyright, patent, trademark, and
          attribution notices from the Source form of the Work,
          excluding those notices that do not pertain to any part of
          the Derivative Works; and

      (d) If the Work includes a "NOTICE" text file as part of its
          distribution, then any Derivative Works that You distribute must
          include a readable copy of the attribution notices contained
          within such NOTICE file, excluding those notices that do not
          pertain to any part of the Derivative Works, in at least one
          of the following places: within a NOTICE text file distributed
          as part of the Derivative Works; within the Source form or
          documentation, if provided along with the Derivative Works; or,
          within a display generated by the Derivative Works, if and
          wherever such third-party notices normally appear. The contents
          of the NOTICE file are for informational purposes only and
          do not modify the License. You may add Your own attribution
          notices within Derivative Works that You distribute, alongside
          or as an addendum to the NOTICE text from the Work, provided
          that such additional attribution notices cannot be construed
          as modifying the License.

      You may add Your own copyright statement to Your modifications and
      may provide additional or different license terms and conditions
      for use, reproduction, or distribution of Your modifications, or
      for any such Derivative Works as a whole, provided Your use,
      reproduction, and distribution of the Work otherwise complies with
      the conditions stated in this License.

   5. Submission of Contributions. Unless You explicitly state otherwise,
      any Contribution intentionally submitted for inclusion in the Work
      by You to the Licensor shall be under the terms and conditions of
      this License, without any additional terms or conditions.
      Notwithstanding the above, nothing herein shall supersede or modify
      the terms of any separate license agreement you may have executed
      with Licensor regarding such Contributions.

   6. Trademarks. This License does not grant permission to use the trade
      names, trademarks, service marks, or product names of the Licensor,
      except as required for reasonable and customary use in describing the
      origin of the Work and reproducing the content of the NOTICE file.

   7. Disclaimer of Warranty. Unless required by applicable law or
      agreed to in writing, Licensor provides the Work (and each
      Contributor provides its Contributions) on an "AS IS" BASIS,
      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
      implied, including, without limitation, any warranties or conditions
      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
      PARTICULAR PURPOSE. You are solely responsible for determining the
      appropriateness of using or redistributing the Work and assume any
      risks associated with Your exercise of permissions under this License.

   8. Limitation of Liability. In no event and under no legal theory,
      whether in tort (including negligence), contract, or otherwise,
      unless required by applicable law (such as deliberate and grossly
      negligent acts) or agreed to in writing, shall any Contributor be
      liable to You for damages, including any direct, indirect, special,
      incidental, or consequential damages of any character arising as a
      result of this License or out of the use or inability to use the
      Work (including but not limited to damages for loss of goodwill,
      work stoppage, computer failure or malfunction, or any and all
      other commercial damages or losses), even if such Contributor
      has been advised of the possibility of such damages.

   9. Accepting Warranty or Additional Liability. While redistributing
      the Work or Derivative Works thereof, You may choose to offer,
      and charge a fee for, acceptance of support, warranty, indemnity,
      or other liability obligations and/or rights consistent with this
      License. However, in accepting such obligations, You may act only
      on Your own behalf and on Your sole responsibility, not on behalf
      of any other Contributor, and only if You agree to indemnify,
      defend, and hold each Contributor harmless for any liability
      incurred by, or claims asserted against, such Contributor by reason
      of your accepting any such warranty or additional liability.

   END OF TERMS AND CONDITIONS

   APPENDIX: How to apply the Apache License to your work.

      To apply the Apache License to your work, attach the following
      boilerplate notice, with the fields enclosed by brackets "[]"
      replaced with your own identifying information. (Don't include
      the brackets!) The text should be enclosed in the appropriate
      comment syntax for the file format. We also recommend that a
      file or class name and description of purpose be included on the
      same "printed page" as the copyright notice for easier
      identification within third-party archives.

   Copyright 2013 Puppet Labs

   Licensed under the Apache License, Version 2.0 (the "License");
   you may not use this file except in compliance with the License.
   You may obtain a copy of the License at

       http://www.apache.org/licenses/LICENSE-2.0

   Unless required by applicable law or agreed to in writing, software
   distributed under the License is distributed on an "AS IS" BASIS,
   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   See the License for the specific language governing permissions and
   limitations under the License.

Modules

Discover

Contribute

Puppet

Premium features

Downloads

Resources

About Forge

Getting Started

corosync

Deprecated

Version information

This module has been deprecated by its author since Mar 21st 2017.

Start using this module

Documentation

Puppet Labs module for Corosync

Basic usage

Configuring primitives

Configuring locations

Configuring colocations

Configuring migration or state order

Corosync Properties

Dependencies

Notes

Contributors

Copyright and License

Types in this module release

cs_location

cs_commit

cs_group

cs_primitive

cs_order

cs_shadow

cs_property

cs_colocation

Dependencies