Proposed RFC for Ubuntu init service checking


#1

Hey everyone,

I have opened up PR 441 in chef-rfc to attempt start a discussion on how
services should be handled. This issue was noticed as I attempted to write
a cookbook that supported Ubuntu 12.04, 13.10, and 14.04.

The TL;DR is basically: you can have any of 3 different ways to
start/restart/stop services in these three different releases and chef
can’t figure out which one without some manual intervention.

Eventually we could leverage this RFC to help out more distros and abstract
away some of the complexity that is init systems.

I’d love some discussion about this, and also I’d like to thank Seth Thomas
(cheeseplus) for being my sounding/editing board on this. I would also
like to thank Steven Danna (ssd7) for pointing me towards Lamont’s fix.


Best Regards,
JJ Asghar
c: 512.619.0722 t: @jjasghar irc: j^2


#2

On Fri Aug 15 11:27:48 2014, JJ Asghar wrote:

Hey everyone,

I have opened up PR 44[1] in chef-rfc to attempt start a discussion on
how services should be handled.

And technically, this is more than that. It means that we can stop
tying a single provider to a given resource on a given platform. The
proliferation of different init systems lately just makes the service
resource a particular pain point. We should also be able to deprecate
the Chef::Platform provider mapping (although I wouldn’t bother ripping
it out for quite awhile, since there are providers in cookbooks out
there which expect to be able to inject mappings into it (e.g. mysql
cookbook). Since this code is added at the provider mapping level it
means that it’ll be transparent to ChefSpec as well and won’t break
anything.

I haven’t tried writing an LWRP with the new methods to see how those
work, but supporting LWRPs should be included in the definition of done.


#3

Oh awesome. So this seems like a better and better idea.

On Fri, Aug 15, 2014 at 2:35 PM, Lamont Granquist lamont@opscode.com
wrote:

On Fri Aug 15 11:27:48 2014, JJ Asghar wrote:

Hey everyone,

I have opened up PR 44[1] in chef-rfc to attempt start a discussion on
how services should be handled.

And technically, this is more than that. It means that we can stop tying
a single provider to a given resource on a given platform. The
proliferation of different init systems lately just makes the service
resource a particular pain point. We should also be able to deprecate the
Chef::Platform provider mapping (although I wouldn’t bother ripping it out
for quite awhile, since there are providers in cookbooks out there which
expect to be able to inject mappings into it (e.g. mysql cookbook). Since
this code is added at the provider mapping level it means that it’ll be
transparent to ChefSpec as well and won’t break anything.

I haven’t tried writing an LWRP with the new methods to see how those
work, but supporting LWRPs should be included in the definition of done.


Best Regards,
JJ Asghar
c: 512.619.0722 t: @jjasghar irc: j^2


#4

]] JJ Asghar

The TL;DR is basically: you can have any of 3 different ways to
start/restart/stop services in these three different releases and chef
can’t figure out which one without some manual intervention.

IIRC, you can use service(8) for all of them, and you should since it
actually handles this correctly.

(As an aside, the code written in Lamont’s pull request is naïve in that
it assumes that installed means running, which is not a valid
assumption. You can (and will) have machines that have sysvinit+systemd
installed, but which use sysvinit as their init system. You’ll find the
same but which use systemd as the init system. There’s also a comment
about problems when multiple init systems claim to support a given
service on a system; this is an implementation problem, but one that
should be given consideration before code is merged.)


Tollef Fog Heen
UNIX is user friendly, it’s just picky about who its friends are


#5

The TL;DR is basically: you can have any of 3 different ways to
start/restart/stop services in these three different releases and chef
can’t figure out which one without some manual intervention.

IIRC, you can use service(8) for all of them, and you should since it
actually handles this correctly.

I’m not 100% sure i agree with this. I’ve tested it a few ways and it seems
that, if anything, it’s inconsistent support.

If we do adopt what Lamont suggests, and I support, we’d have some
consistency.

Or did i miss understand what you’re saying?