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

[Mike < >]

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

[0]: fail if init doesn't exist:
https://github.com/opscode/chef/commit/4d626652b04cce2e7246abe03f0c2088b0bc3229
[1]: http://tickets.opscode.com/browse/CHEF-3380
[2]: COOK-3380 fix:
https://github.com/opscode/chef/commit/6f06f4d8a4f0c024f7af2eab85e60a5b1908e47c

On Mon, Dec 10, 2012 at 9:50 PM, AJ Christensen 
<
 >
 wrote:
> I get that, but this is happening because the provider for *your* platform
> has been updated to be more explicit about convergence requirements.
>
> Am I misunderstanding something here? The (plain) service resource will
> perform a platform lookup [0] to figure out which provider to use, which is
> where the convergence requirement assertion regarding init scripts is coming
> in (because you are on a Redhat platfom). Similarly, on my platform (Debian
> / Ubuntu), additional assertions are placed around the availability of tools
> like update-rc.d.
>
> The service resource definitely is not at fault here -- there is no way for
> it to know up front which provider will be used during convergence when a
> lookup happens for it to place compile-time validation around parameters;
> even so, this generally is only used for simple format validation of inputs,
> not interacting with the system to determine convergence requirements.
>
> If I wanted to tell a particular service resource to skip the provider
> behaviour that Chef will run due to the platform I'm on, I'd specify a
> different provider -- Chef::Provider::Service::Simple [1], in the case I
> didn't want to have the requirement of an init script -- explicitly in the
> resource declaration. Even before why run was added, the code in your recipe
> would behave differently on all systems, each running their own Service
> provider implementation.
>
> Hope this helps!
>
> AJ
>
> [0] platform lookup:
> https://github.com/opscode/chef/blob/master/lib/chef/platform.rb#L169
> [1] simple service provider:
> https://github.com/opscode/chef/blob/10-stable/chef/lib/chef/provider/service/simple.rb
>
>
>
> On 11 December 2012 15:02, Mike 
> <
 >
>  wrote:
>>
>> I'm not asking for a workaround.
>>
>> I'm stating that I think that the 'service' resource, which accepts
>> "start", "stop", et al, variables, and does not require an ini script,
>> fails a Chef run on any version with why-run mode - not the resource
>> itself - and this seems like a failing to me.
>>
>> -M
>>
>>
>> On Mon, Dec 10, 2012 at 8:57 PM, AJ Christensen 
>> <
 >
>> wrote:
>> > You could explicitly use the Init or Simple service provider instead of
>> > using the Redhat one, if you aren't using enable/disable, etc. These
>> > obviously won't work without the presence of an init script (no?)
>> >
>> > Cheers,
>> >
>> > --AJ
>> >
>> >
>> > On 11 December 2012 14:53, Mike 
>> > <
 >
>> >  wrote:
>> >>
>> >> Anyone care to chime in on this? Is this a legit bug, or am I seeing
>> >> something wrong?
>> >>
>> >> On Fri, Dec 7, 2012 at 1:42 PM, Mike 
>> >> <
 >
>> >>  wrote:
>> >> > Recently I came across an oddity in Chef 10.14.x/10.16.x, that looks
>> >> > like a regression in behavior.
>> >> >
>> >> > I looked around for any existing tickets on this particular topic,
>> >> > and
>> >> > couldn't find anyone with this specific issue.
>> >> >
>> >> > Running a recipe like this[0] that declares a service resource based
>> >> > on parameters available[1] runs correctly on 10.12, but then breaks
>> >> > on
>> >> > anything past that [2].
>> >> >
>> >> > Error message on my CentOS system comed from here[3].
>> >> >
>> >> > It looks as though the assumption is that the service provider will
>> >> > always have an init script, typically to do the `action :enable`
>> >> >
>> >> > Since this is not the case, maybe one fix would be to modify this
>> >> > line[4] to only cover 'enable', and handle checking for a
>> >> > start_command, stop_command, etc and if none are provided, then use
>> >> > the init.d script logic.
>> >> >
>> >> > I am curious to know if anyone else is using non-init service
>> >> > invocations and have come across this, also if anyone wants to fix
>> >> > it,
>> >> > I'm happy to help out.
>> >> >
>> >> > -Mike Fiedler
>> >> >
>> >> > [0]: https://gist.github.com/4235082#file_default.rb
>> >> > [1]: http://docs.opscode.com/resource_service.html
>> >> > [2]: https://gist.github.com/4235082#file_chef_10.14.4_output.txt
>> >> > [3]:
>> >> >
>> >> > https://github.com/opscode/chef/blob/10-stable/chef/lib/chef/provider/service/redhat.rb#L50
>> >> > [4]:
>> >> >
>> >> > https://github.com/opscode/chef/blob/10-stable/chef/lib/chef/provider/service/redhat.rb#L48
>> >
>> >
>
>