Largish commit. In essence it implements a couple of features. multip…

[spo0nman]

Details:
manifests/params.pp
manifests/init.pp
manifests/config.pp
    - $::redis::params::redis_init_template
      $::redis::params::redis_init_file_mode
      $::redis::redis_binary_path
      $::redis::redis_binary_name
      Running multiple instances will give a bunch of redis-server processes, unless the name of the binary has the name of the instance, it becomes very confusing to see what process is running which instance. This makes the output nice. We need to modify the init file in order to pass the instance name to e process name.
       ps: I don't have suse/bsd/debian to test on. this may be wrong for those platforms.

    - $::redis::params::slaveof_port
      Multiple instances run on different ports and need multiple entries for master/slave, thus, we need to move the slave port to be independent of the slave of host. This would need changes in existing configuration. if someone upgrades.

    - $::redis::params::client_output_buffer_limit_normal
      $::redis::params::client_output_buffer_limit_slave
      $::redis::params::client_output_buffer_limit_pubsub
      Made the output buffer limits configurable.

    - $::redis::params::instances
      Takes a hash of instances. All the config variables that can be tuned in config can be passed along with each instance. if nothing is passed. the redis defaults from params and config are observed.

    - $::redis::provider
      Allows one to overload the puppet provider in case you use a different one from the default puppet provider

    - $::redis::params::sentinel_init_template
      template/redis-sentinel.init.redhat.erb
      start-stop-daemon is not a CentOS thing, so we need a Redhat/CentOS specific init script.

manifests/sentinel.pp
    - $::redis::params::sentinel_log_file
      Sentinel needs its own log file and should not write to the same one as redis.

    - $::redis::instances
      Sentinel is configured with multiple instances. the name of sentinel master is the name of the instance.

    - $::redis::sentinel::members
      $::redis::params::sentinel_discover_master
      $::redis::params::sentinel_members
      $::redis::params::sentinel_multiple_instances
      Sentinel configuration is tricky, You can bake who the master is in the configuration, but as the infrastructure lives on, the reality of who the sentinel thinks is the master for an instance changes. With the discovered_master flag you can use a simple .erb script (discover_master.erb) to find out wholl the sentinel think the master is for a given instance. This allows you to reflect the current master in the sentinel configuration. If none of the sentinels are reachable or if the qourem is not reached, it defaults to the first item of $::redis::sentinel::members

[petems]

Closing in favour of #200