Add support for OpenBSD

[buzzdeee]

OpenBSD doesn't use a config file, it just passes flags to the service, via the service_flags.
Therefore most of the parameters are ignored. Some scaffolding is done, i.e. around firewall rules, and configuring instances.

To help prevent accidental breakage, a couple of tests related to OpenBSD added as well.

[saz]

Instead of adding the service_flags parameter, wouldn't it be better to use rely on the already existing parameters and concat those as value for service_flags? It looks weird to me, to have a lot of parameters, which are not used at all and then list everything, more or less, again.

[buzzdeee]

Hi,

How about just making the statement regarding the service_flags more obvious, that most of the other parameters are ignored on OpenBSD? I.e. instead of having it buried in the list of other parameters, add a section of how to use the module on OpenBSD? Could you live with that?

TL'DR:
Since my memcached module (https://forge.puppetlabs.com/modules/buzzdeee/memcached/readme) got marked as "scheduled for deprecation", I was looking at either updating, or find a viable more widely used module. To ease support on multiple OS, the second option is more appealing, and your module seems to be best maintained one.

Can't tell how many others are using my module, but with the service_flags parameter, it would be an easy drop-in replacement, instead of having to go through all these parameters, and splitting off, what previously was in the service_flags before.

For a long time Puppet on OpenBSD users, who may have a new requirement to manage memcached, they will look out for such service_flags parameter, and they'll be happy to find it, as there are also many other modules around, that support it. It would keep the configuration as native to the OS as possible, just KISS.

I see how others handle the service_flags:
https://github.com/bodgit/puppet-memcached/blob/master/manifests/service.pp

This is quite a lot of code, where many things could go wrong. Would need a lot of spec tests added to the module.
I haven't checked, if your module handles ANY parameter memcached supports. Also, if ever memcached gets a new parameter in the future, the module would have to be extended as well to add support for it. With the service_flags, it will immediately use any future parameter that might be added.

If there would be a configuration file, and all those parameters would go through a template, I'm fully with you, and it definitely would make sense to reuse them.

If you really don't want to support the service_flags, I could use bodgit approach, but to be honest, it scares me a bit, and I'm sitting on the fence, if it then not makes more sense to just update my module to modern standards, like a number of my other modules.

[saz]

Thank you for the detailed explanation! I tried to come up with a better way, but everything seems to be more complicated than necessary. :(

[saz]

@buzzdeee I'll do a new release asap. I'm also curious if there's a way to let people know, that this module might be an alternative to your module on the forge? 🤔

[buzzdeee]

On my GitHub repo, I added a deprecation notice, and pointing to your module on the Forge and GitHub.
For the forge, I don't know if there's a sane way. I'll reach out on #puppet-modules in the Puppet community Slack channel.

[buzzdeee]

Found this place where to ask for deprecations and transfers: puppetlabs/forge_issues#22