0
votes

I am trying to have a git repository which manages my environment. I have set of lwrp written for specific tasks. These lwrps internally depends on many community cookbooks.

Each of my cookbook has a Berksfile where I specify dependency resolution. In the root folder of my repository I have a main Berksfile which lists all the cookbooks I want from my repository.

What I want now is, when I do a berks install from the root location, it should fetch my cookbooks and then parse through them to find individual berks file from each of those cookbooks and resolve all dependencies. However it is not behaving like that.

Anybody has any idea regarding this ? Is this common scenario of how Berks work ? Or am I missing something so that the dependencies are not resolved?

To give more info : My cookbook has this berksfile

source 'https://supermarket.chef.io'
cookbook 'apache_spark', '~> 1.2.12'

And the apache spark has internal dependency on

cookbook 'monit', github: 'phlipper/chef-monit', tag: '1.5.2'
1
At least I assume that it works for cookbooks that don't have a recursive dependency pointing to a Git repo...StephenKing
Yeah I guess its kind of a duplicate question. And We dnt have a solution yet I believe for "recursive dependency pointing to a Git repo"Arjun K R

1 Answers

1
votes

This is a duplicate of the mentioned question but as that doesn't have a super-detailed answer, I'll put more on here.

As stated in the other answers, Berksfile directives are "non-transitive". The dependencies in a cookbook's metadata.rb are symbolic dependencies, just a name and a version constraint without information on where to get it from. Each tool that works with cookbooks has a different understanding of how to process these symbolic dependencies, for example when you run a berks install you might be pulling dependencies from Supermarket or GitHub but when chef-client processes them it gets everything from the Chef Server. Keeping this split between symbolic dependencies vs. where to get them from allows a lot of tools to co-exist. The Berksfile provides additional data about where to download specific cookbooks from, either augmenting or replacing information from the symbolic dependencies, but as these extra directives aren't part of the cookbook metadata they can't be done recursively.

The big problem is that Supermarket is a flat namespace so there can only be one cookbook called monit. This leads many people to not publish things on Supermarket and depend on them via git source directives. This means depends "monit" is no longer as clear as it should be. This should really be considered a bug with the unpublished cookbook, but I understand peoples' reluctance to rename their cookbooks in order to release them properly.

The usual fix is either to copy-pasta some stuff into your new Berksfile from your upstreams, or to create an isolated cookbook universe in a private Supermarket instance (or equivalent Chef Server organization) where you upload just the things you want, and in doing so depends "monit" becomes unambiguous again.