That sounds like an anti pattern to me. No 2 tools should manage the same resource

Usually I would agree with the comment#183 (comment)

But other modules are doing the same: class parameter to set the ensure or enable state.

@ttousai can you please rebase your branch?

I tend to agree with@TheMeier on this one.
We usually have params to manage the service or not, and if we do manage it we have params to ensure stopped/running and enabled/disabled ( at boot )

If there is another tool involved managing the service state that tool should manage the enabled/disabled state as well.

There are reasons why puppet should not start the service. e.g. nfs ist started by pacemaker/corosync.
From my point of view the request to have a parameter makes sense.
Maybe the description was a little bit misleading.

To me the example you mention is exactly the kind of edge case where I would setmanage_server_service to false and manage the service in aprofile class.

For e.g. pacemaker setups, everything should be managed by Puppet, except the state of the service, as this should be handled by pacemaker.

There's already a parameter availableserver_service_ensure.
Shouldn't it be enough to allowundef to be set here?