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 <
">
> 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 <
">
> 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.
-- Joshua Timberman, Chef.
|