Why-run requires an init script for 'service' resrouce


#1

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 this0 that declares a service resource based
on parameters available1 runs correctly on 10.12, but then breaks on
anything past that 2.

Error message on my CentOS system comed from here3.

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
line4 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


#2

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 miketheman@gmail.com 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 this0 that declares a service resource based
on parameters available1 runs correctly on 10.12, but then breaks on
anything past that 2.

Error message on my CentOS system comed from here3.

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
line4 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


#3

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 miketheman@gmail.com 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 miketheman@gmail.com 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 this0 that declares a service resource based
on parameters available1 runs correctly on 10.12, but then breaks on
anything past that 2.

Error message on my CentOS system comed from here3.

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
line4 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


#4

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 aj@junglist.gen.nz 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 miketheman@gmail.com 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 miketheman@gmail.com 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 this0 that declares a service resource based
on parameters available1 runs correctly on 10.12, but then breaks on
anything past that 2.

Error message on my CentOS system comed from here3.

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
line4 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


#5

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:


1 simple service provider:

On 11 December 2012 15:02, Mike miketheman@gmail.com 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 aj@junglist.gen.nz
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 miketheman@gmail.com 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 miketheman@gmail.com 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 this0 that declares a service resource based
on parameters available1 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

[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


#6

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:


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 aj@junglist.gen.nz 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 miketheman@gmail.com 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 aj@junglist.gen.nz
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 miketheman@gmail.com 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 miketheman@gmail.com 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 this0 that declares a service resource based
on parameters available1 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

[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


#7

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


#8

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 dan@kallistec.com 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


#9

On Tuesday, January 1, 2013 at 12:32 PM, Mike wrote:

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?

I don’t think so. Can you create one?

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.

Most of the providers have evolved organically as the community finds new use cases and contributes patches to make the providers work for that use case. Unfortunately, there is some unresolved friction around this now that we’ve added some new concepts to providers. In the long term, we need to clarify some of the rough edges around how we use resources to model bits of the system. But in the short term, we should just “make it work.”

I’m happy to help with this any way I can.
Patches accepted, please feel free to ask if you have questions about the new why run APIs.


Daniel DeLeo

-Mike