GitLab

Also make sure that a daemonized sentinel properly produces
a pid file so the init script can stop the sentinel.

Until an initscript is available for redis-sentinel in its package[1]
we need to roll our own. This change adds that by creating a templated
initscript with the sentinel config file and service owner and group
as template variables that get filled in.

Testing this revealed some bugs and misfeatures that are also addressed
in this change:

* apt systems want the redis and redis-sentinel processes to daemonize
  (systemd-based) rpm does not. This was not reflected in the params
  defaults, nor reflected in the sentinel configuration template. Now
  it is.

* the package_name for redis-sentinel was not being passed in as a
  parameter, instead it was just using the params.pp default for
  redis server. When [1] is resolve, it will likely mean a different
  package for redis-sentinel so we need there to be a separate parameter
  for the sentinel package that gets installed. For now the name of
  the existing package is used.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775414

Trailing commas are not allowed in the JSON spec. This
causes an error when using librarian-puppet and the
:git option.

We are using puppet-stdlib with ensure_resource so we need to add it in
requirements.

When running Redis Server & Redis Sentinel on the same node, avoid a
resource dupplication with package resource.

Without this it's possible that on a clean machine where only sentinel
is being installed the install will fail because the 'redis' user
(who owns the *.puppet config file) will not yet exist.

By ensuring that the redis package is installed explicitly first the
user will be there.

The previous pull request related to this problem added the package
dependency but did not make the ordering explicity.

The sentinel service needs to make sure that the redis package has
been installed on the machine where sentinel is being run. All my
previous testing had assumed that there would be a redis server and
sentinel on the same machines. This doesn't have to be the case, so
the manifest needs to make allowances for that.

Without these changes a from-scratch redis-sentinel.conf can be
created that is not writable by the redis user, as such the sentinel
server will exit immediately after starting.

This change ensures the permissions of the *.puppet file and then
preserves those permissions upon copy. Unfortunately the copied-to
file is hard to test in the spec files, so verification in test is
no longer available. It works properly in manual testing.

Doing so exposed some redundant parameters that have been removed
as well as an incorrect default value that has been corrected.

Also add tests for paramafied class creation.

Useful while debugging issues with the redis-shutdown command in
the 2.8.15 rpm of redis. The problem is fixed with 2.8.18.

Note the commented out lines in the sentinel.pp for the config_dir
and log_file resources. If these are there we get duplicate
resources. A few options to deal with this:

* Not worry about it: the dpkg and rpm packages make sure they are
  there anyway, we're really just insuring existence of default
  things. This only becomes a problem if someone wants to write
  log files and config files in unusual places, but if that's the
  case they are probably managing that anyway.

* Extract the conflicting resources to their own classes which both
  redis and redis-sentinel use. This gets complicated in the face of
  the way redis::params is used as a super class and other
  inclusions are done.

* Require stdlib and use ensure_resource (untested, but based on
  reading the docs it seems like it ought to work).

I'm inclined to the former.

Still missing and to do:

* confirm system restart on config file changes
* flesh out the tests
* implement monitoring of multiple masters (add loop to the conf
  file template and change data structure)

This allows the sentinel to write to the config file without
puppet making changes unless it has bonafide config changes it would
like to do.

This is done by having a 'refreshonly' exec which subscribes to a
config file that sits alongside the config file that sentinel
actually uses.

This is just the basics so far, for sake of getting something in
place to build from.

Some assumptions are made:

* It's best to follow the model of putting constants in the
  params.pp and inheriting from that.
* A single params.pp is used (rather than creating one specifically
  for sentinel) because some existing redis params are used in sentinel.pp.

Things still to do:

* ensure service is installed and running
* ensure service is restarted on config file change
* flesh out tests
* deal with the fact that sentinel use the config file to keep state

On the latter, the most likely right thing to do is create the
config file on a different name and only copy it if there are
changes. See example from a different patchset trying the same
thing:

https://github.com/victorgp/puppet-redis/blob/f7be4187bbb77f991a53b004f8e3f2512c0c1b48/manifests/sentinel.pp#L96-L107

Does nothing yet, will be building support for sentinel on this
branch.