[chef] Re: Better workflow for actively-developed cookbooks

[Peter Donald < >]

On Saturday, June 23, 2012, Wes Morgan  wrote:

I'm more or less using your approach, Jeremiah. The friction I ran into was when I wanted to roll a new release of a cookbook I manage (linode) from a git repo. The "knife cookbook metadata [ linode | . | -o ./ linode | metadata.rb]" commands wouldn't generate a metadata.json file for me. 

I don't have my code base in front of me but I typically run a command like

knife cookbook metadata from file somepath/metadata.rb

 

It wanted the cookbook to be in cookbooks/linode relative to cwd. Hence my "tied to a particular directory layout" comment.

So that sent me down the librarian-chef :path => (sorry, I couldn't resist), which then had different behavior than I expected given its similarity to the bundler option of the same name.

For the specific case of metadata.json generation, it would be nice if knife would work directly on a metadata.rb file. That would at least solve my immediate issue. And I'm sure I'll learn to live with the way L-C works. Overall it's a big improvement over what I was doing before.

Wes

On Jun 22, 2012, at 1:52 PM, Jeremiah Snapp wrote:

I've still been really pleased with the way I use Librarian-Chef.  I let it take over my cookbooks directory within my chef-repo and make sure I don't version control that directory so instead it is just a "build artifact" as Jay calls it.  I keep the chef-repo/cookbooks directory as the only cookbook_path in my knife config so I can easily 'knife cookbook upload -a'.

There are two locations for cookbooks I am developing.

1. Forked Cookbooks which I put outside my chef-repo directory under ../cookbooks and then I use :path in Librarian-Chef Cheffile to bring those into the chef-repo/cookbooks "build" directory.
   When I'm done developing these cookbooks I push them to the git server and change their entries in Cheffile to :git entries.
2. Private? Cookbooks which I put inside my chef-repo/site-cookbooks directory so they get version controlled with the rest of the chef-repo.  These Cheffile entries are permanently :path entries regardless of whether or not I'm making changes to them.

If I make changes to either of these two types of cookbooks and I want to test those changes I just run "librarian-chef install" and the chef-repo/cookbooks build directory picks up all the changes.

Then I can either run "chef-solo", "vagrant provision" or "knife cookbook upload -a" depending on how I'm testing.

I understand what you mean but I wouldn't say knife is "tied to a particular directory layout".  You can add the -o option to knife subcommands to specify what paths to look for the cookbook.

I find that is a small inconvenience compared to the flexibility otherwise provided by Librarian-Chef and my usage.

I don't bother with the Librarian-Chef knife integration pretty much just because I don't like that I can't run many (all?) knife commands unless I'm in the chef-repo where librarian-chef has been initialized.  The knife commands just break and I find that to be too restrictive.

Jeremiah

On Fri, Jun 22, 2012 at 1:24 PM, Wes Morgan < > wrote:

Thanks for your clarifications. I understand most of it, and I'm not actually asking for those things to be changed. I don't think. :)

What I really need, and what I should have said first:

With bundler, when I specify a :path => option, it just uses the code in that path directly. Is there a reason Librarian-Chef can't do that and instead copies it into the cookbooks dir? If there were just the one directory for the path'd cookbook, that would pretty much solve my problem. It sounded like the L-C knife integration could manipulate knife's cookbook path, so I was surprised it didn't do that and just point it at the directory specified in the :path => option.

Wes

On Jun 22, 2012, at 1:04 PM, Jay Feldblum wrote:

Wes,

Librarian-Chef takes over your repository's ./cookbooks/ directory by design. It is no longer your directory. It is no longer source code. It no longer belongs to the source repository. It is now a build artifact that is produced by Librarian-Chef on your behalf, on-command, as per the instructions you give to it on the command line and in your Cheffile. The readme talks more about this and gives some tips for dealing with cookbooks you are working on: https://github.com/applicationsonline/librarian.

A future version of Librarian-Chef may allow you to configure the choice of directory.

Librarian-Chef assumes that you have a way to develop and test the underlying cookbooks independently of any consuming infrastructure repository. Sadly, the state of the world is not yet such that most cookbooks are developed this way. So there will be some friction over the near term, friction like the kind you have discovered, as the state of the world progresses in that direction.

Until then, the options available may seem like a choice between, on the one hand, a whole lot of work in testing a cookbook fork independently and in isolation and, on the other hand, hacks with the git and

-- 
Cheers,

Peter Donald