Class[riak]: Parameters and Configuration

The Riak Class

The module is centered around the riak class. The all-defaults configuration looks like this:

class { 'riak': }

It's 'anti-class' that you use when you want to remove Riak from a node, looks like this:

class { 'riak':
  ensure => absent,
}

Version of Riak

The module has some version hard-coded (at the time of writing it's 1.2.0), but you can upgrade by setting the version parameter:

class { 'riak':
  version   => '1.3.0',
  use_repos => false,
}

When you set use_repos = false, the module will download the rpm/deb rather than going through Basho's repositories.

Custom download of Riak

The module has a hard-coded download url, but you can change it by setting the download parameter:

class { 'riak':
  download => 'https://internal-ci:8888/riak.custom-1.2.1-lol1.rpm',
  download_hash => 'https:///internal-ci:8888/riak.custom-1.2.1.lol1.rpm.sha' #sha2-file
}

The hash-file should follow the format from Basho's own download formats.

Custom App.config file

class { 'riak':
  source => [ "puppet:///modules/site/riak-app.config.${$environment}",
              'puppet:///modules/site/riak-app.config' ]
}

This allows you to simply customize your App.config file. If you set this parameter, it overrides the default code-generation way of specifying the App.config file, and the parameter is mutually exclusive with template.

Custom Template

class { 'riak':
  template => 'puppet:///modules/site/App.config.erb'
}

In your erb-template, you can access the variable appcfg, which is a hash. So you could e.g. write:

[{ riak_core, [ { mysetting, "<%= @appcfg[:riak_search][:enabled] ? 'yey' : 'of noes' %>" } ] }].

The template parameter is mutually exclusive with the source parameter. If you set this parameter, it overrides the default code-generation way of specifying the App.config file.

log_dir

Sets the directory for logs for riak.

erl_log_dir

Sets the directory for erlang's virtual machine logs for riak. This is by default the same as log_dir.

data_dir

Where you wish to store the data of riak.

service_autorestart

Default: true

Whether to restart the node (i.e. the riak service) when you change the configuration.

disable

Default: false

Whether to disable the riak service. If you set this to true, the service will progress into the stopped state. Different from absent in that it doesn't remove riak from the node.

disableboot

Default: false

Whether to disable the service from booting up. If also disable is set, the service is also stopped right away.

ulimit

Default: 4096

The max no. of open file descriptors, see the docs.

limits_template

Default: riak/limits.conf.erb

The template to evaluate and use for /etc/security/limits.conf.

App.config properties and values

You can modify App.config by passing a hash to either cfg or to vmargs_cfg, which feeds vm.args. Here's an example of adding a https binding with a custom certfile and keyfile.

class { 'riak':
  cfg => {
    riak_core => {
      https => {
        "__string_${$::ipaddress}" => 8443
      },
      ssl => {
        certfile => "${etc_dir}/cert.pem",
        keyfile  => "${etc_dir}/key.pem"
      }
    }
  }
}

The configuration options are equal to any that Riak accepts. Have a look at Basho's wiki for a complete listing, or at the rebar-file in their repo.

The prefix __string_ is one of many. They work like this:

Puppet Array

Create an Erlang tuple:

['__tuple_', 46, $::ipaddress, 'whatever']

Create an Erlang list:

['__list_', 46, $::ipaddress, 'whatever']

Puppet String

Create an Erlang atom:

'__atom_certfile'

Create an Erlang binary string:

'__binary_mystringcomeshere'

Puppet Hash

All keys in a puppet hash are translated by default to Erlang atoms, because that's what the config uses most of the time. In the case that you need a key to be translated to a string, e.g. like in this code:

class { riak:
  cfg => {
  # ...
  riak_core => {
    http => {
      "__string_${$::ipaddress}" => 8098
    }
  # ...
  }
}

you simply prefix the key with __string_.

All hashes will be sorted on keys, in each layer, to make sure that the files change as little as possible from puppet run to puppet run.