gfs2

Table of Contents

1. Module Description - What the module does and why it is useful
2. Setup - The basics of getting started with gfs2
   • What gfs2 affects
   • Setup requirements
   • Beginning with gfs2
3. Usage - Configuration options and additional functionality
4. Reference
5. Limitations - OS compatibility, etc.
6. Development - Guide for contributing to the module
7. Acceptance Tests

Module Description

This module supports the Global File System and ensures that proper firewall rules are used to support GFS2.

Setup

What gfs2 affects

gfs2 installs required packages and ensures that GFS2 services are running. Additionally, it will make use of simp/iptables to ensure that the proper ports are open, if it is installed.

Setup Requirements

Your yum repository must have the following packages:

• ricci
• sg3_utils
• modcluster
• rgmanager
• gfs2-utils
• lvm2-cluster
• cmano

If you are using xenu or xen0, your yum repo additionally must have:

• kmod-gnbd-xen
• libvirt.${::hardwaremodel}

Finally, a server must have:

• luci

Beginning with gfs2

To install GFS2 and manage proper services, simply include the module.

include 'gfs2'

or

classes:
- gfs2

Usage

I want to manage a GFS2 server

include 'gfs2'
include 'gfs2::server'

classes:
- gfs2
- gfs2::server

I'm using simp/iptables

Using SIMP iptables, you can also manage your firewall and restrict the nodes that are allowed to connect to the cluster.

classes:
- gfs2
- gfs2::server
- gfs2::cluster_allow

gfs2::server::cluster_nets: 10.10.50.0/24
gfs2::cluster_allow::cluster_nets: 10.10.50.0/24

Reference

Classes

Public Classes

• gfs2
• gfs2::server
• gfs2::cluster_allow

Limitations

SIMP Puppet modules are generally intended to be used on a Red Hat Enterprise Linux-compatible distribution.

Development

Please read our Contribution Guide and visit our Developer Wiki

If you find any issues, they can be submitted to our JIRA.

Acceptance tests

To run the system tests, you need Vagrant installed.

You can then run the following to execute the acceptance tests:

   bundle exec rake beaker:suites

Some environment variables may be useful:

   BEAKER_debug=true
   BEAKER_provision=no
   BEAKER_destroy=no
   BEAKER_use_fixtures_dir_for_modules=yes

• BEAKER_debug: show the commands being run on the STU and their output.
• BEAKER_destroy=no: prevent the machine destruction after the tests finish so you can inspect the state.
• BEAKER_provision=no: prevent the machine from being recreated. This can save a lot of time while you're writing the tests.
• BEAKER_use_fixtures_dir_for_modules=yes: cause all module dependencies to be loaded from the spec/fixtures/modules directory, based on the contents of .fixtures.yml. The contents of this directory are usually populated by bundle exec rake spec_prep. This can be used to run acceptance tests to run on isolated networks.