Cookbook Dependency Version Question

Chef Infra (archive)
1

Ohai!,

Google and docs.opscode.com haven’t yielded me any answers so hoping someone
might shed some light on how conflicting depedencies versions are handled. The
recent discussions around wrapper cookbooks and library cookbooks had sparked
some discussion for us, albeit the question is more general than the wrapper
cookbook stuff.

Given the following scenario:

  • Cookbook1 with versions 1.0.0 and 2 on the chef server
  • Cookbook2 has depends "Cookbook1", "= 1.0.0"
  • Cookbook3 has depends "Cookbook1", "= 2.0.0"

From what I’ve seen in the cookbook cache, it seems that only one copy of any
cookbook is every downloaded locally. If so I assume the above example false
into the “don’t do this” category?

What is the best way to handle situations where you have multiple cookbooks
that might have a common dependency, but each of those cookbooks might want a
different version of that dependency?

Thanks

2

Any run list which combines cookbook1+2+3 in the same Environment will
not be satiable due to a constraint and the run will error during
run_list expansion phase prior to compilation.

Valid run_list combinations:

cookbook1 + cookbook2 (dependency)
cookbook1 + cookbook3 (dependency)

I would advise performing infrastructure-wide maintenance to bring any
legacy dependencies up to the latest matching. This may involve
updates to 'cookbook2'.

If this is not a possibility, then the run_lists / cookbooks can be
segregated with different Environments -- pin = 1.0.0 in environment1,
pin 2.0.0 in environment2, converge the nodes in different
environments with more flexible dependency restriction. I would only
advise making use of this in the interim while your systems are moved
toward stable consistent dependencies. Indeed, "don't do this"
category applies.

Anyone else have any suggestions?

Cheers,

AJ

On 16 May 2013 10:54, davidpetzel@gmail.com wrote:

Ohai!,

Google and docs.opscode.com haven't yielded me any answers so hoping someone
might shed some light on how conflicting depedencies versions are handled. The
recent discussions around wrapper cookbooks and library cookbooks had sparked
some discussion for us, albeit the question is more general than the wrapper
cookbook stuff.

Given the following scenario:

  • Cookbook1 with versions 1.0.0 and 2 on the chef server
  • Cookbook2 has depends "Cookbook1", "= 1.0.0"
  • Cookbook3 has depends "Cookbook1", "= 2.0.0"

From what I've seen in the cookbook cache, it seems that only one copy of any
cookbook is every downloaded locally. If so I assume the above example false
into the "don't do this" category?

What is the best way to handle situations where you have multiple cookbooks
that might have a common dependency, but each of those cookbooks might want a
different version of that dependency?

Thanks

3

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.

4

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

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.

5

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" ukio@gmx.de 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/-"

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.