Banging my head over a Chef cookbook glitch and inflexible Librarian
After frustration over the deprecation of Berkshelf 2 (“WARNING: It is advised at this time that you use Berkshelf 3. Berkshelf 2 is no longer being actively developed and has a number of significant issues related to dependency resolution that Berkshelf 3 fixes”), deprecation of Vagrant Berkshelf and the minimal documentation of still-in-beta Berkshelf 3, I decided to give librarian-chef a try.
Librarian initially seemed to work beautifully. But it fell down when it hit a bug in a cookbook I was trying to use:
================================================================================ Recipe Compile Error in /root/chef-solo/cookbooks-2/postfix-dovecot/recipes/default.rb ================================================================================ ArgumentError ------------- You must supply a name when declaring a package resource Cookbook Trace: --------------- /root/chef-solo/cookbooks-2/postfixadmin/recipes/default.rb:60:in `from_file' /root/chef-solo/cookbooks-2/postfix-dovecot/recipes/postfixadmin.rb:22:in `from_file' /root/chef-solo/cookbooks-2/postfix-dovecot/recipes/default.rb:23:in `from_file' Relevant File Content: ---------------------- /root/chef-solo/cookbooks-2/postfixadmin/recipes/default.rb: 59: 60>> package pkg_php_mbstring do 61: not_if do pkg_php_mbstring.nil? end 62: action :install 63: end
For my OS,
pkg_php_mbstring is nil. But that means “package pkg_php_mbstring” translates to “package nil,” which is illegal.
Fixing this tiny bug would be easy if I controlled the cookbook, but Librarian does. I cloned the Github repo and modified the offending lines, but Librarian wouldn’t let me use my version of the cookbook because it’s included by another cookbook, which is included by another cookbook. I would have to clone them all and redefine the entire dependency chain to get my tiny bug fix in.
This is a known weakness of Librarian:
one of the major annoyances with Chef: since librarian-chef managed these cookbooks and the directories in which they lived, the workflow for editing them was tedious and hackish. Editing stuff you don't own [involves]: * clone down other cookbook * move librarian-managed cookbook somewhere else * symlink your cloned cookbook in its place so knife can find it * knife cookbook upload <cookbook> * whack moles * git commit * remove the symlink to the cloned cookbook * put the librarian-managed cookbook back where it was (or delete it) * bundle exec librarian-chef update <- to update your Cheffile.lock to have the right version of the cookbook you just edited * bundle exec librarian-chef install <- to install the version you just specified There are ways to make the above process shorter such as scripting steps 2, 3, 7, and 8 as well as saving steps 9 and 10 until you are totally done working. And, to be fair, librarian-chef served the very important purpose at one time. However, the process of editing stuff you don't own is still tedious and less than ideal.
I really want to love Chef, but I keep hitting issues like this. Sigh.
Posted by James on Tuesday, March 04, 2014