- 03 Feb, 2015 2 commits
-
-
Lee Packham authored
-
Lee Packham authored
-
- 02 Feb, 2015 1 commit
-
-
Lee Packham authored
-
- 19 Jan, 2015 3 commits
-
-
Tom De Vylder authored
-
Chris Dent authored
Also make sure that a daemonized sentinel properly produces a pid file so the init script can stop the sentinel.
-
Chris Dent authored
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
-
- 16 Jan, 2015 1 commit
-
-
Stanley Stuart authored
Trailing commas are not allowed in the JSON spec. This causes an error when using librarian-puppet and the :git option.
-
- 15 Jan, 2015 2 commits
-
-
Emilien Macchi authored
We are using puppet-stdlib with ensure_resource so we need to add it in requirements.
-
Emilien Macchi authored
When running Redis Server & Redis Sentinel on the same node, avoid a resource dupplication with package resource.
-
- 09 Jan, 2015 1 commit
-
-
Chris Dent authored
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.
-
- 07 Jan, 2015 1 commit
-
-
Chris Dent authored
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.
-
- 05 Jan, 2015 4 commits
-
-
Chris Dent authored
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.
-
Tom De Vylder authored
-
Tom De Vylder authored
-
Tom De Vylder authored
-
- 17 Dec, 2014 2 commits
-
-
Tom De Vylder authored
-
Chris Dent authored
-
- 16 Dec, 2014 1 commit
-
-
Chris Dent authored
Doing so exposed some redundant parameters that have been removed as well as an incorrect default value that has been corrected.
-
- 15 Dec, 2014 2 commits
-
-
Chris Dent authored
Also add tests for paramafied class creation.
-
Chris Dent authored
-
- 11 Dec, 2014 3 commits
-
-
Chris Dent authored
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.
-
Chris Dent authored
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)
-
Chris Dent authored
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.
-
- 10 Dec, 2014 2 commits
-
-
Chris Dent authored
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
-
Chris Dent authored
Does nothing yet, will be building support for sentinel on this branch.
-
- 22 Oct, 2014 4 commits
-
-
Tom De Vylder authored
-
Tom De Vylder authored
-
Tom De Vylder authored
-
Tom De Vylder authored
-
- 21 Oct, 2014 1 commit
-
-
Tom De Vylder authored
-
- 29 Aug, 2014 4 commits
-
-
Tom De Vylder authored
-
Tom De Vylder authored
-
Tom De Vylder authored
-
Tom De Vylder authored
-
- 28 Aug, 2014 6 commits