[chef-dev] Re: Re: Re: Re: Re: Re: dependency spaghetti

[Ranjib Dey < >]

i had suggested chef-berks already. Above everything this reduces the load on chef server. and we get rid of storing community cookbooks in our chef servers..

On Thu, Oct 3, 2013 at 1:09 AM, Sean OMeara < " target="_blank"> > 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 < " target="_blank"> > wrote:

> On Thu, Oct 3, 2013 at 2:32 AM, Noah Kantrowitz < " target="_blank"> > 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