Feature test vs platform test


#1

Hi all,

I was wondering if there was any recommended way to feature test for
upstart vs SysV init. I’ve seen the examples of branching on platform, but
in our hybrid environment we have versions of debian that use init, and
some that use upstart, so platform branching isn’t specific enough for me.

Thanks for any info/advice you can provide.


#2

if File.exists?(’/etc/init’) maybe?

–Noah

On Jan 28, 2014, at 8:52 AM, Gregory Patmore gregorypatmore@gmail.com wrote:

Hi all,

I was wondering if there was any recommended way to feature test for upstart vs SysV init. I’ve seen the examples of branching on platform, but in our hybrid environment we have versions of debian that use init, and some that use upstart, so platform branching isn’t specific enough for me.

Thanks for any info/advice you can provide.


#3

There’s a few stacks out there that have installed upstart, but still have
the init setup installed.

To frame the discussion some, I’m trying to adjust the application_nodejs
cookbook to remove the hard dependancy on ubuntu+upstart

I’ve been researching, and so far I’m thinking that maybe the
node[“chef_client”][“init_style”] variable may be my best bet?
I’m not too familiar with the chef_client object from the recipe
perspective, so unless someone can point me somewhere, I’d have to test the
behavior from within an LWRP.

To be fair, the cookbook worked for me anyway on Centos 6.3, but without
the upstart configuration file getting dropped off. I just don’t want
anyone to rely on all the features being executed as expected so I’m trying
to implement a branching in the provider that adheres to the original
functionality but branches for non-upstart installations.

On Tue, Jan 28, 2014 at 1:30 PM, Noah Kantrowitz noah@coderanger.netwrote:

if File.exists?(’/etc/init’) maybe?

–Noah

On Jan 28, 2014, at 8:52 AM, Gregory Patmore gregorypatmore@gmail.com
wrote:

Hi all,

I was wondering if there was any recommended way to feature test for
upstart vs SysV init. I’ve seen the examples of branching on platform, but
in our hybrid environment we have versions of debian that use init, and
some that use upstart, so platform branching isn’t specific enough for me.

Thanks for any info/advice you can provide.


#4

I wouldn’t rely on the chef-client attribute. Here’s why:

  1. You’re creating a dependency in your cookbook on the chef-client
    cookbook, which brings along it’s own dependency chain. This may be
    confusing to users of your cookbook. Especially if they’re eg, using chef
    solo.

  2. The init style defaults in the chef-client cookbook attempt to be "sane"
    for the platforms it assumes. This isn’t the definitive list, despite the
    extensive number of platforms. As you found, there can easily be
    conflicting init styles in families or even in the same platform.

I would detect the appropriate command or file required by the desired init
system and definitely ensure it is an attribute that end users can change
if desired. I would also try to keep as much of that logic out of recipes
or provider actions, if applicable, so they are easier to read and
understand without a bunch of platform specific nonsense (where nonsense is
ruby code, to non rubyists :)).

On Tuesday, January 28, 2014, Gregory Patmore gregorypatmore@gmail.com
wrote:

There’s a few stacks out there that have installed upstart, but still have
the init setup installed.

To frame the discussion some, I’m trying to adjust the application_nodejs
cookbook to remove the hard dependancy on ubuntu+upstart

I’ve been researching, and so far I’m thinking that maybe the
node[“chef_client”][“init_style”] variable may be my best bet?
I’m not too familiar with the chef_client object from the recipe
perspective, so unless someone can point me somewhere, I’d have to test the
behavior from within an LWRP.

To be fair, the cookbook worked for me anyway on Centos 6.3, but without
the upstart configuration file getting dropped off. I just don’t want
anyone to rely on all the features being executed as expected so I’m trying
to implement a branching in the provider that adheres to the original
functionality but branches for non-upstart installations.

On Tue, Jan 28, 2014 at 1:30 PM, Noah Kantrowitz <noah@coderanger.net<javascript:_e({}, ‘cvml’, ‘noah@coderanger.net’);>

wrote:

if File.exists?(’/etc/init’) maybe?

–Noah

On Jan 28, 2014, at 8:52 AM, Gregory Patmore <gregorypatmore@gmail.com<javascript:_e({}, ‘cvml’, ‘gregorypatmore@gmail.com’);>>
wrote:

Hi all,

I was wondering if there was any recommended way to feature test for
upstart vs SysV init. I’ve seen the examples of branching on platform, but
in our hybrid environment we have versions of debian that use init, and
some that use upstart, so platform branching isn’t specific enough for me.

Thanks for any info/advice you can provide.


Joshua Timberman, Chef.


#5

excellent point. thanks. I wasn’t thinking about chef-solo runs. I also heartily agree that external dependencies are best left to the env/role/attribute/recipe level and kept out of the deeper provider level. (a caveat though, I’ve had some great success letting an LWRP manage a LWRP specific chef tag… don’t hate me)

it’s unfortunate that the application_nodejs has this upstart dependency baked into the provider, am I correct in my understanding that the default Chef::Provider::Service::Init should determine the correct subclass to instantiate? If so, is there a recommended way to determine which one it would use? or even better, which ones are supported by a host?

Sent from my iPhone

On Jan 29, 2014, at 2:11 AM, Joshua Timberman joshua@getchef.com wrote:

I wouldn’t rely on the chef-client attribute. Here’s why:

  1. You’re creating a dependency in your cookbook on the chef-client cookbook, which brings along it’s own dependency chain. This may be confusing to users of your cookbook. Especially if they’re eg, using chef solo.

  2. The init style defaults in the chef-client cookbook attempt to be “sane” for the platforms it assumes. This isn’t the definitive list, despite the extensive number of platforms. As you found, there can easily be conflicting init styles in families or even in the same platform.

I would detect the appropriate command or file required by the desired init system and definitely ensure it is an attribute that end users can change if desired. I would also try to keep as much of that logic out of recipes or provider actions, if applicable, so they are easier to read and understand without a bunch of platform specific nonsense (where nonsense is ruby code, to non rubyists :)).

On Tuesday, January 28, 2014, Gregory Patmore gregorypatmore@gmail.com wrote:
There’s a few stacks out there that have installed upstart, but still have the init setup installed.

To frame the discussion some, I’m trying to adjust the application_nodejs cookbook to remove the hard dependancy on ubuntu+upstart

I’ve been researching, and so far I’m thinking that maybe the node[“chef_client”][“init_style”] variable may be my best bet?
I’m not too familiar with the chef_client object from the recipe perspective, so unless someone can point me somewhere, I’d have to test the behavior from within an LWRP.

To be fair, the cookbook worked for me anyway on Centos 6.3, but without the upstart configuration file getting dropped off. I just don’t want anyone to rely on all the features being executed as expected so I’m trying to implement a branching in the provider that adheres to the original functionality but branches for non-upstart installations.

On Tue, Jan 28, 2014 at 1:30 PM, Noah Kantrowitz noah@coderanger.net wrote:
if File.exists?(’/etc/init’) maybe?

–Noah

On Jan 28, 2014, at 8:52 AM, Gregory Patmore gregorypatmore@gmail.com wrote:

Hi all,

I was wondering if there was any recommended way to feature test for upstart vs SysV init. I’ve seen the examples of branching on platform, but in our hybrid environment we have versions of debian that use init, and some that use upstart, so platform branching isn’t specific enough for me.

Thanks for any info/advice you can provide.


Joshua Timberman, Chef.