Manually setting service_provider parameter
dagobert opened this issue · 8 comments
From somewhere along 5.x you changed the parameter $service_provider in params.pp to automagically find out the "correct one". As for me using Debian 8.6 you opt for systemd as the appropriate provider. I am still using "debian" which defaults to the old wheezy and prior.
It would be great if you could add the option to set the service provider manually. This way you could keep your good way of checking but also allow other non default choices.
Keep up the great work.
Would you like to send an PR against develop branch?
I have created a pull request.
On a side note, isn't puppet checking the appropriate service provider (see https://docs.puppet.com/puppet/latest/reference/type.html#service-attribute-provider) meaning you do not need to implement it at all?!
provider
The specific backend to use for this service resource. You will seldom need to specify this — Puppet will usually discover the appropriate provider for your platform.
The problem is/was that in "older" puppet version, the auto provider discovery wasn't the best. I don't know how it is at the moment. If it works well with >3.8.x, then we can remove our own detection.
The problem is that RedHat's gunicorn package doesn't provide an init script, so we have to set one via a template. It actually has nothing to do with the service resource. Relevant part of config is here: https://github.com/echocat/puppet-graphite/blob/master/manifests/config_gunicorn.pp#L38-L82
(There may be other places where $graphite::params::service_provider is checked, but this is the one that I know, because I programmed it.)
Since it's conditional logic and not just a call to service, the only way to ascertain the system's service provider is either to:
- Use some ugly conditional logic like we have now, or
- Bump the required
puppetlabs-stdlibversion to 4.10, which introduced theservice_providerfact.
The service_provider fact uses the same logic as the service provider uses internally.
I see. I am not using puppet on other systems than Debian and Ubuntu. there at least I never found any problems with auto sensing the service provider. I just wanted to know :)
I guess sticking with the requirements at 3.8 should be preferred, since Debian stable it still at this version and it has a major install base.
Sorry, perhaps I was unclear; this has nothing to do with auto sensing service providers. In puppet (all versions), there is no way to ask it what service provider it is using. So, if you need to have some conditional logic that relies on knowing the service provider (like this module does for picking a template), you have to hack in that functionality yourself. Which is why you'll see modules that do this kind of thing.
The only elegant solution for this is requiring the puppetlabs-stdlib module at version >= 4.10, as it has a custom service_provider fact. This has no relation to what puppet version you're using; puppetlabs-stdlib <= 5.0 is backwards-compatible to Puppet 2.7.
(The override for service provider is a good idea, I was just commenting on the "auto-detection" part.)