[chef-dev] Re: Re: Re: Re: why-run requires an init script for 'service' resrouce

[Daniel DeLeo < >]

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 [0], without a proper "Hey, there's backwards-breaking

stuff in this version!" notification, in going from version 10.12.0 to

10.14.0.

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 [1] and reported as

Fixed in 10.14.0, but the change there [2] 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

stated them.

And thereby running identically across any platform.

Best,

-Mike

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.

-- 

Daniel DeLeo