Stricter data types

[ekohl]

This sets data types for most parameters that previously had none. It also moves static defaults from params.pp to inline. While this duplicates a few between Redis and the sentinel, the user would already need to know these were linked. The benefit is a much more readable reference documentation.

[Dan33l]

I don't understand why it is flagged backwards-incompatible.
Just someone that use knif like a fork will have incompatibility.

[ekohl]

I don't understand why it is flagged backwards-incompatible.
Just someone that use knif like a fork will have incompatibility.

There are changes. Often they're (much) stricter and users can run into this. Where strings used to be accepted, now only integers are. Given the tests are also failing on this indicates I may have been a bit too aggressive in some places.

[ekohl]

Note to self: $hash_max_ziplist_entries and $hash_max_ziplist_value are only relevant on 3.0. Looks like Ubuntu 16.04 is the only platform that ships it out of the box.

[igalic]

Can someone explain to me what '__VALUE__' is — or was, in this code?

[ekohl]

My guess is that it was a clear placeholder for easy testing. Now that this is green I plan to go over every config item to see if they're still correct. I already found 2 parameters that no longer exist in 3.2+. That makes me think about dropping Ubuntu 16.04 which is the last that ships Redis 3.0.

[igalic]

when will Canonical drop 16.04?

[ekohl]

Support stops in April 2021, but I want to add a note that it can work if you install the PPA so you have a version newer than 3.0. Maybe we can set manage_repo to true by default on 16.04.

[dom-nie]

@ekohl I looked at most of variables you are touching and these could use some more tightening and safer limits on types.

[ekohl]

Awesome @dom-nie! Going over the parameters was on my TODO list for today and I highly appreciate it.

[ekohl]

I think this is now ready for a final review. The String entries have been tightened to String[1] as well.