[chef] Re: Re: Re: Re: Re: Re: Re: Demonstrating the Power of Chef, Librarian and Vagrant

[Jay Feldblum < >]

Torben,

Fantastic question. You're describing the standard way people might use Chef, which is "Infrastructure as Code." This is what Opscode documents in their tutorials and in their Wiki.

But the purpose of Librarian-Chef is to help people use Chef in a subtly different, stricter way, which I call "Infrastructure as Application." The difference is that, in an application, you don't just have a loosely-related set of modules in source control. You have a single integrated codebase in source control, which requires that you have a single integrated set of dependencies, with their exact versions and sources, documented in source control. This results in every node getting the exact same cookbooks as are listed in source control each and every run.

Librarian-Chef is not a tool to help fetch cookbooks. It is a tool to help you automatically enforce a policy of having a single integrated codebase in source control with a single integrated set of dependencies. As part of that enforcing that policy, it provides useful services: it can fetch cookbooks, it can tell you which cookbooks are outdated, it can update cookbooks one-by-one and all-at-once, and it can hook into knife. There are some things it does not do, such as enforce that the resolved cookbooks are synced to your chef-server (although boundary-knife-plugins can help there). This is what Bundler does for the gems used by any Ruby application.

This policy will probably be acceptable to most people most of the time, since most people most of the time will not have a strong need to have two versions of the same cookbook in their infrastructure repository at the same time. Some people may even agree with the policy, and Librarian-Chef can help them enforce it. If you are faced with a particular incompatibility, then you can certainly fork one of the cookbooks in question and change it to be compatible, so that you can end up with a single integrated codebase with a single integrated set of dependencies.

If what you need is simply a tool to help fetch cookbooks, without enforcing the "Infrastructure as Application" policy, there are a number of others tools available that do that.

On Mon, Apr 23, 2012 at 12:45 PM, Torben Knerr < " target="_blank"> > wrote:

Hi Jay,

thanks for the quick reply!

I see the value in not having the same cookbook in different versions, but it is also very restricting and I also see some cases where you might need that.

In the example above, consider that "foo" and "bar" are well tested cookbooks not owned by me. As long as I use them independently (i.e. no node has both of the cookbooks) that dependency to different versions of "baz" is totally fine, and would become a conflict only when I used both cookbooks on the same node, isn't it so?

Now to resolve the conflict, I would have to patch "foo" to be compatible with "baz" 2.0, which might not be an easy task and would potentially break it, so I'd rather not touch that thing!

I'm wondering: shouldn't librarian-chef be more liberal wrt to defining dependencies to different versions of the same cookbook, and on the other hand the chef server (or knife) be more strict wrt to configuring a node with conflicting dependencies?

Cheers,
Torben