On Tuesday, December 11, 2012 at 5:03 PM, Mike wrote:
Thanks for the Simple service provider, I looked into it, and while
yes, it seems like applying that would solve the immediate problem, it
doesn’t solve the fact that a backwards-breaking change was introduced
in this commit , without a proper “Hey, there’s backwards-breaking
stuff in this version!” notification, in going from version 10.12.0 to
Agreed - the service provider itself isn’t to blame, rather the
implementation of the inspection around whether the provided service
resource needs to check for an init script or not is faulty.
This was brought up, in a fashion, in COOK-3380  and reported as
Fixed in 10.14.0, but the change there  only narrows the scope of
service resource actions.
One could state that the more accurate thing it is to look for
platform defaults for commands that are not explicitly stated in the
service provider invocation.
As to behaving differently on various platforms - one could argue that
by explicitly stating the commands in the service resource should
override any platform-specifics, since the operator has explicitly
And thereby running identically across any platform.
Apologies for the late reply.
First off, it’s our goal that minor and patch release upgrades of Chef should not require users to make changes to existing recipes. Therefore, this behavior is a regression.
As for the larger questions, I think this definitely deserves some thought. AJ makes a good point that a Red Hat service resource can be reasonably expected to meet the implicit requirements of the Red Hat service toolchain. This is complicated, however, by the fact that on a Red Hat system, a service resource will use the Red Hat provider by default, requiring the user to explicitly opt-out if something else is desired. In the early days of Chef, it was quite common that people would understand the resource/provider concept and explicitly select providers for a resource. I almost never see this anymore, and in any case I think only Chef experts understand how/why to use this technique. I don’t think that running a service outside of the Red Hat (or debian/ubuntu/whatever) framework is a use case that should require expert knowledge, so it is worthwhile to make a change to address the issue.
The most expedient thing is to simply skip the checks for an init script when the commands required for the given action are specified explicitly, e.g., if a start and check command are given, then action :start wouldn’t require the init script to be present.
Alternatively, implementation-specific resources could be added for each kind of service provider, e.g., redhat_service, simple_service, etc. The providers could then be maximally strict about enforcing requirements, and the user could select the implementation based on service name.
Finally, the service resource could select a provider at runtime based on user input, so a service resource with explicit start/stop/status commands would select the “Simple” provider instead of the Red Hat one.
Among these options, I think the first is the best for now. If you’ve been following the thread on “local file copy resource,” it seems pretty clear that we don’t have a consensus on how best to model things on a fine-grained level, so I would avoid making a change that impacts modeling considerations until we have an idea of what’s “optimal” there.