Update to 7.9

Update all references to 7.9

README.md

@@ -59,18 +59,18 @@ For systems using APT, the latest packages of the latest release will be install
 
 ```puppet
 class { ::gluster::repo:
-  version => '3.5.2',
+  version => '7.9',
 }
 ```
 
-For systems using YUM, the latest package from the 3.8 release branch will be installed. You can specify a specific version and release:
+For systems using YUM, the latest package from the 7 release branch will be installed. You can specify a specific version and release:
 
 ```puppet
 class { ::gluster::repo:
-  release => '3.7',
+  release => '7',
 }
 class { ::gluster:
-  version => '3.7.12',
+  version => '7.9',
 }
 ```
 
@@ -93,7 +93,7 @@ Currently, RHEL 6, RHEL 7, Debian 8, Raspbian and Ubuntu provide native Gluster
       server  => true,
       client  => true,
       repo    => true,
-      version => 3.5.1-1.el6,
+      version => 7.9-1.el7,
     }
 
 Note that on Red Hat (and derivative) systems, the `version` parameter should match the version number used by yum for the RPM package.
@@ -105,7 +105,7 @@ This class installs **only** the Gluster client package(s). If you need to insta
 
     class { ::gluster::client:
       repo    => true,
-      version => '3.5.2',
+      version => '7.9',
     }
 
 Use of `gluster::client` is not supported with either `gluster::install` or `gluster::init`.
@@ -132,7 +132,7 @@ If a `volumes` parameter is passed, the defined Gluster volume(s) can be created
       repo    => true,
       client  => false,
       pool    => 'production',
-      version => '3.5',
+      version => '7.9',
       volumes => {
         'data1' => {
           replica => 2,

examples/01_simple.md

@@ -14,7 +14,7 @@ To create a simple two-node replicated Gluster volume, you could use the followi
         client                 => true,
         repo                   => true,
         use_exported_resources => false,
-        version                => '3.5.2',
+        version                => '7.9',
         volumes                => {
           'g0' => {
             replica => 2,

examples/02_simple.md

@@ -14,7 +14,7 @@ To create a simple two-node replicated Gluster volume, you could use the followi
         server  => true,
         client  => true,
         repo    => true,
-        version => '3.5.2',
+        version => '7.9',
       }
 
       # make sure the service is started

examples/03_exported_resources.md

@@ -12,8 +12,8 @@ Again, assuming two servers each with one brick:
         client  => true,
         repo    => true,
         pool    => 'production',
-        version => '3.5.2',
-        volumes                => {
+        version => '7.9',
+        volumes => {
           'g0' => {
             replica => 2,
             bricks  => [ 'srv1.local:/export/brick1/brick',

examples/04_hiera.md

@@ -20,7 +20,7 @@ Your `/etc/puppet/hieradata/common.yaml` file could then contain:
     gluster::client: true
     gluster::pool: production
     gluster::repo: true
-    gluster::version: '3.5.2-1.el6'
+    gluster::version: '7.9-1.el7'
 
 You can then simply apply `class { ::gluster: }` to any hosts and they will use the upstream Gluster repo, install version 3.5.2-1.el6 of both the server and client, and join the `production` pool.
 
@@ -32,22 +32,22 @@ In this way, you could have two servers (srv1.local and srv2.local) operating in
     gluster::client: false
     gluster::pool: testing
     gluster::repo: true
-    gluster::version: '3.6.1-1.el6'
+    gluster::version: '7.9-1.el7'
 
 /etc/puppet/hieradata/hosts/srv2.local.yaml:
 
     ---
     gluster::client: false
     gluster::pool: testing
     gluster::repo: true
-    gluster::version: '3.6.1-1.el6'
+    gluster::version: '7.9-1.el7'
 
 If you support multiple major versions of Red Hat (and derivative) systems, you can still easily use Hiera data to define a common package version for all systems. Your `/etc/puppet/hieradata/common.yaml` file would then contain:
 
     ---
     gluster::client: true
     gluster::pool: production
     gluster::repo: true
-    gluster::version: "3.5.2-1.el%{::operatingsystemmajrelease}"
+    gluster::version: "7.9-1.el%{::operatingsystemmajrelease}"
 
 Hiera will interepret the value of `%{::operatingsystemmajrelease}` as a fact of the same name, and replace the Red Hat major version number in this string.

examples/05_client.md

@@ -6,7 +6,7 @@ Included in this module is a gluster::client class. This is a helper class that
     node /app[1-3].local/ {
       class { gluster::client:
         repo    => true,
-        version => '3.6.2',
+        version => '7.9',
       }
     }
 

examples/06_yum_priorities.md

@@ -3,12 +3,13 @@ Yum Priorities
 There may arise [situations](http://blog.gluster.org/2014/11/installing-glusterfs-3-4-x-3-5-x-or-3-6-0-on-rhel-or-centos-6-6-2/) where a vendor-supplied package is newer than those provided by the gluster.org repositories. In these cases, you can use yum priorities to ensure that the Gluster repository is consulted **before** the vendor channel.
 
 If you use Hiera data:
-    ---
-    gluster::client: false
-    gluster::pool: production
-    gluster::repo: true
-    gluster::repo::yum::priority: 50
-    gluster::version: '3.5.2-1.el6'
+```
+gluster::client: false
+gluster::pool: production
+gluster::repo: true
+gluster::repo::yum::priority: 50
+gluster::version: '7.9-1.el7'
+```
 
 This ensures that dependency resolution is confined to the repository and revision you specified, and prevents Yum from helpfully trying to use the latest version available.
 

manifests/params.pp

@@ -7,7 +7,7 @@
   # parameters dealing with installation
   $install_server = true
   $install_client = true
-  $release        = '7.3'
+  $release        = '7.9'
   $version        = 'LATEST'
 
   # we explicitly do NOT set a priority here. The user must define