[chef-dev] Re: dependency spaghetti

[Bryan Taylor < >]

Why would I want to do dependency checking on the client? That will just lengthen bootstrapping timeframes in the happy path, and decrease reliability of client runs when I don't have the dependencies I need. There are a fairly small set of platforms. It seems to me a basic question of configuration management is whether or not I can successfully deploy a given run list on a node of a given platform. If I have to actually do this experiment, and the experiment sometimes fails, I don't think I'm really managing my configurations very well. 

The problem here seems pretty clear: cookbooks should declare (and test) what dependencies must be satisfied for each platform that the cookbook supports, while in any particular chef environment, the deployer only cares about some subset of platforms, and for a particular cookbook, the deployer may have made different platform choices yet again. As the administrator for a chef managed environment, I want to be able to scope default cookbook dependency checking to my chosen default platform set, and for a particular cookbook to deviate from the default, so that the server prevents me from trying to execute run lists that will fail because of unsatisfied dependencies without bothering me about unsatisfied dependencies for platforms I've chosen not to use.

From: Noah Kantrowitz < "> >
Date: Thursday, October 3, 2013 3:17 AM
To: Sean OMeara < "> >
Cc: Dimitri Aivaliotis < "> >, Bryan Taylor < "> >, Blake Irvin < "> >, " "> Dev" < "> >
Subject: Re: [chef-dev] Re: Re: Re: Re: dependency spaghetti

If you factor in that depsolver feeds back into dependency resolution it would be a lot to move on to the client. Also re: per platform dependencies, that's only one use case out of many, another big one is service frameworks like the runit cookbook only being used if initstyle is set to runit.

--Noah

Sean OMeara < "> > wrote:

Why can't we just switch to client-side dependency solving instead? (ala berks)

-s

On Thu, Oct 3, 2013 at 2:48 AM, Noah Kantrowitz < " target="_blank"> > wrote:

On Oct 2, 2013, at 11:04 PM, Dimitri Aivaliotis < "> > wrote:

> On Thu, Oct 3, 2013 at 2:32 AM, Noah Kantrowitz < "> > wrote:
>> There has been a long running concept to turn #suggests into an optional form of #depends, so it would have the same effect as depends if the cookbook is found in terms of triggering a download and loading in the right order, but wouldn't cause a failure if that cookbook wasn't found. Maybe after I get this dialect stuff squared away I'll write up that patch :)
>>
>
> I like this.  It's better than 'suggests' just being a no-op.  An
> alternative may be to enable case statements in metadata.rb.  The
> individual depends could then properly be resolved based on platform
> or recipe usage.  The client can then filter based on the case in the
> cookbook's metadata, and only download those cookbooks it really
> needs.

The cookbook metadata isn't actually code, the Ruby format is just convenience so you don't have to write the (rather long and complex) JSON yourself. More specifically the cookbook dependency tree is resolved on the server, not the client, so whatever the solution is it has to be fully declarative.

--Noah