Hi everybody,
we recently started a discussion on the different ways you can lock the cookbook dependency graph for a given node:
1. use Chef environments
2. use metadata.rb
3. use Policyfile (work in progress)
The discussion of environments vs. metadata started here on the list...
...then continued on a github with @danielsdeleo, proposing a new mechanism called Policyfile:
Looking at the Policyfile approach, I like how the sketched terminal session reads [1], but I'm also afraid that it will add even more possibilities on how to center your workflow around Chef. It would be the next competitor to "roles" vs. "environment cookbooks" vs. "metadata" vs. "policyfile".
So I'm wondering: can't we solve the problem with the tools at hand or do we have to invent something new for it?
Almost everything that is described in the desgin principles [2] could be easily solved by using cookbooks + metadata.rb today. You just have to make sure that the contents of Berksfile.lock get translated into metadata.rb depends statements. That's what I was calling "top-level" cookbook but you could also call it "policy cookbook" if you will.
Think of this:
* for each node you have 1 top-level cookbook
* this top-level cookbook has all the pinned versions from Berksfile.lock via "depends" statements in its metadata.rb
* in the the node's run_list is just the default recipe (or any other) of the top-level cookbook, which defines the actual "run_list" that you would otherwise have in roles via "include_recipe"
* your top-level cookbook for sure has a version, as any other cookbook too
* in your environments you only pin the top-level cookbook's version (all transitive dependencies are pinned via the top-level cookbook's metadata)
What would be missing from this approach?
The only new thing proposed in [2] was the ability to uniquely identify non-released development versions. The proposal suggests to use a hash over the cookbook contents instead of name + version. I see the need for properly identifying in-development versions as well, but IMO using a hash would just obscure things. Instead I would rather see prerelease and build identifiers being supported by the Chef cookbook versioning scheme (see CHEF-4027 [3]) -> as we have for Ruby gems today.
Just saying: let's start simplifying and improve the tools around the concepts we currently have, not inventing additional and competing concepts that make everything more complex. Reuse the existing concepts, establish conventions, and foster them by making sure the tools we use promote them.
That was quite much to digest... hope that makes still sense :-)
Cheers,
Torben