I’m running Chef Server 12.2.0, and I’ve noticed an odd behavior with one of my wrapper cookbooks - it doesn’t use the latest versions of cookbooks uploaded to the Chef server.
On the Chef server, we have two custom cookbooks, cookbookA v 0.1.28 and cookbookB v 0.2.11. cookbookB references cookbookA like so:
# cookbookB/recipes/default
include_recipe 'cookbookA::some_recipe'
# cookbookB/metadata.rb
...
version '0.2.11'
depends 'cookbookA'
# cookbookB/Berksfile
source 'https://supermarket.chef.io'
metadata
cookbook 'cookbookA', git: 'git@github.com:user/chef-repo.git', rel: 'cookbookA'
However, all nodes running the cookbookB::default recipe call cookbookA version 0.1.16 rather than version 0.1.28. Any idea how I can fix this without hard-coding the cookbookA version in cookbookB/metadata.rb?
The Berksfile has no effect on Chef’s version solver. It sounds like Policyfiles are more of what you are looking for if you want to pull snapshots from git and have production obey them. Otherwise if B depends on a specific version of A then the dependency metadata should reflect that.
As a side question on this - dependancy resolution - we have quite a few cookbooks that depend on other cookbooks and make use of “version pinning” using environment cookbooks (we have not moved to policy files yet). Once in a while, because of some obscure dependancy of a dependency not under our control, we can never get the latest version of our own cookbooks. We can isolated who is responsible by removing the cookbooks that we know - but it is still pretty long.
Is there a way to see how the decision was made and pinpoint which cookbook constraint is responsible ?
This happens both in development with Berks and when converging via chef-client.
Thanks, Noah! One follow-up question: I’m now running into mixed dependency problems where two separate cookbook dependencies require two separate versions of ohai:
$ chef install
Building policy my-cookbook
Expanded run list: recipe[my-cookbook::default]
Caching Cookbooks...
Installing my-cookbook >= 0.0.0 from path
Installing other-cookbook1 >= 0.0.0 from git
Installing other-cookbook2 >= 0.0.0 from path
Installing other-cookbook3 >= 0.0.0 from path
Installing other-cookbook4 >= 0.0.0 from path
Installing other-cookbook5 >= 0.0.0 from git
Error: Failed to generate Policyfile.lock
Reason: (Solve::Errors::NoSolutionError) Unable to satisfy the following requirements:
- `ohai (~> 3.0)` required by `sysctl-0.7.5`
- `ohai (~> 2.0)` required by `nginx-2.7.6`
Do I have any options besides (1) downgrading sysctl to a version compatible with ohai (~> 2.0) or (2) opening an issue with the nginx repo requesting they upgrade their ohai dependency to ohai (~> 3.0)?
You may want to look at Noah’s knife-solve plugin.
Nathan Clemons
DevOps Engineer
Moxie Cloud Services (MCS)
O +1.425.467.5075
M +1.360.861.6291
E nclemons@gomoxie.com
W www.gomoxie.comhttp://www.gomoxie.com/
Thanks @nclemons
While it does give me the list, I still end up wit the same probelms. EG (I renamed / removed cookbooks for display):
± |master ?:3 ✗| → knife solve corp_sys corp_rr
Solving [corp_sys, corp_rr] in _default environment
<<< aprox 20 cookbooks >>>
…
corp_rr 0.3.0
corp_sys 3.0.18
…
± |master ?:3 ✗| → knife cookbook list
…
corp_rr 0.5.14
corp_sys 3.0.18
…
As you can see the resolver is NOT getting the latest corp_rr - this is in the unconstrained default environment. I know this happens because somewhere in the dependency list ( 20+ cookbooks) there is a restriction that bubbles up. I want that displayed. I will look at what @jcderose was doing with the chef install above - is that the actual output ? but in my case - it does resolve, but I need to know which cookbook forced the constraint.
You might consider Batali as an alternative solver. It can resolve branching dependency trees (giving you a copy of each version) so that you can install all the cookbooks that will be needed on the server.
Batali: https://github.com/hw-labs/batali
For more on the usage and rationale, we have a blog post here: http://www.heavywater.io/blog/2015/03/17/batali/