[chef] Re: Re: Re: Cookbook Dependency Version Question

[Torben Knerr < >]

Waaaah - looks like the lower half of my message got lost, gnarf :-/

Trying to continue where it got lost:

On May 16, 2013 7:43 AM, "Torben Knerr" < "> > wrote:
>
> I'd do a combination of both:
>
> * in the top-level (or application or wrapper) cookbook representing your node pin all dependency version in the metadata.rb
>
> * in the environment pin only the top-level cookbook's version
>
> This way you can have both versions of Cookbook1 at the same time being used in the same environment (on different nodes though)
>
> For the dependency resolution tools this means that you can _not_ have a per chef-repo Cheffile / Berksfile (they would report exactly the conflict you mention

Instead you'd have to use a Cheffile/Berksfile reflecting the dependencies in metadata.rb in each of the top-level cookbooks git repos. From there on you have two choices:

a) resolve and upload the top-level cookbooks from within the toplevel cookbooks git repo

b) if you want to have it all in one place (eg chef repo), then use a yaml file which contains the name/version/git-location of the top-level cookbooks plus a script which does roughly this: "clone tlc from git repo to tmpdir && cd tmpdir && resolve deps to chefrepo/cookbooks/<tlc-name>-<tlc-version>"

This works well for us. We are using b) because we like to have chef-repo/cookbooks/ namespaced per tlc and thus can easily inspect their dependencies.

It is DRY in that you specify the tlc's dependencies only in a single place, and (even more important!) it does not artificially restrict us to only ever have a single version of Cookbook1 within an environment (if we had used a per chef-repo Cheffile/Berksfile)

Cheers, Torben

>>
>> Thanks AJ,
>>   So, currently we don't have this situation, but it came up as a hypothetical situation when we started discussing the library/wrapper paradigm. Currently today we do use environmental constraints, and rarely rely on the setting a version in the cookbooks metadata.rb.
>>
>> That said, the trend we felt like we were seeing is folks suggesting to use the wrapper cookbook s(I think some are calling them Top Level Cookbooks in a slightly different context) and to pin dependencies in the metadata.rb
>>
>> As we are seeing it the environment approach is known to us ,and typically we've been happy with that approach. It has the down side of an "all or nothing" when we bump a dependency, but since we go through a few levels of environments before we get to something important that has so far been ok for us.
>>
>> So we were looking to try and draw a parallel in the wrapper/library situations. We understand there is no right or wrong answer, so I'm definitely interested in folks experiences with this.
>>