On Tue, Apr 24, 2012 at 12:22 PM, Jay Feldblum < " target="_blank"> > wrote:
Torben,- I'm not sure how to handle multiple versions of the same cookbook in the same git repository.My idea was to use tags, as in:cookbook "rvm", :git => "https://github.com/fnichol/chef-rvm", :ref => "v0.7.1"- The chef-server has a dependency resolver which will put together consistent run-lists based on the cookbooks, including multiple versions of the same cookbook, that have been uploaded to the chef-server.I assumed that, but didn't know for sure. Can you point me to any documentation about it? I would be especially interested if you could make it fail if it detects a dependency version conflict in a run_list...Cheers,TorbenChef supports a wide variety of ways to use it. Uploading multiple versions of the same cookbook seems to be one of the intended ways to use it. In that case, you would be relying on the chef-server to deliver a consistent run-list to each node.Cheers,JayOn Tue, Apr 24, 2012 at 2:11 AM, Torben Knerr < " target="_blank"> > wrote:
Am 23.04.2012 19:40 schrieb "Jay Feldblum" < " target="_blank"> >:
>
> 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.
>Thanks for the explanation, the "single integrated set of dependencies" policy was not clear to me, I saw it rather as a generic dependency management solution for cookbooks (like maven for cookbooks if you will).
My requirements would be:
- keep my cookbooks in their own git repos outside the chef-repo (don't like nested git repos)
- pull in 3rd party cookbooks as dependencies (via git, opscode api, etc...) in a declarative manner (like Cheffile)
- allow multiple versions of the same cookbook in the chef-repo
- detect and handle dependency version conflicts when putting together the run_list (does chef do this already???)Except for the third point librarian-chef supports this already, and it would probably be easy to fork librarian for that.
But the more I am thinking about it the more I believe that either
a) I am doing something wrong (against the intended use of chef), or
b) this should be an integral part of chef itselfHelp, I'm confused... :-)
Torben
> 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
>
>
Archive powered by MHonArc 2.6.16.