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

[Mike < >]

Happy New Year! 2013 is bound to be an awesome year!

> 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.
Has a ticket been filed for this?

> 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.
I was under the (wrong) impression that this was already the case.
The approach I assumed to make sense was that "explicit overrides
implicit/defaults", as we see in other places.

I'm happy to help with this any way I can.

-Mike

On Thu, Dec 20, 2012 at 2:06 PM, Daniel DeLeo 
<
 >
 wrote:
>
> 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
>