Personally, the almost-forced repo-per-cookbook approach is one thing that bothers me about berkshelf.
*Some* cookbooks are indeed independent entities, and should have their own repos.
But role cookbooks, and in my case a master cookbook that controls it all, tend to inherently be integrated with each other and should be in the same git repo. A change to one of these cookbooks will often lead to changes in others, and those should be tracked together.
So which cookbook *should* have their own repos? Generally, cookbooks with a well-defined, stable interface should have their own repos. Can you think of the cookbook's interface as an API? If not, then it should better be placed in a common repo.
The problem with berkshelf is that you can specify a git repository as source per cookbook, but you can't really specify a git repository that contains multiple cookbooks.
Kevin Keane
The NetTech
http://www.4nettech.com
Our values: Privacy, Liberty, Justice
See https://www.4nettech.com/corp/the-nettech-values.html
-----Original message-----
From: Yoshi Spendiff < >
Sent: Monday 13th April 2015 11:49
To:
Subject: [chef] Single Repo vs Repo per cookbookHi,I know this horse has been flogged to death but I've a slightly different permutation on the question that I'm having trouble working out.I'm fully on board with having cookbooks be isolated objects with their own dependencies, using Berkshelf and testing cookbooks in isolation, but I'm in a situation here where we're putting in a new Chef implmenetation and I need to convince people here to use one repo per cookbook with examples of why, otherwise it will be done in one repo. It's easy to show arguments for why cookbooks should be essentially independent and developed/tested as such but I'm not sure that necessarily means they have to be in their own repository each.
The other way around this that I can see is to simply use directories under the cookbooks repo to do the same thing (not a chef repo, more just like a cookbook specific repo). So you would have a structure like this:
-cookbooks_repo
--company-apache2 (wrapper cookbook)
---Berksfile
--company-php (wrapper cookbook)
---Berksfile
--company-cookbook (role containing cookbook)
---Berksfiles
---recipes\webserver.rb
---metadata.rb (pointing to company-apache2 and company-php)The Berksfiles for the downstream cookbooks could reference the others by git ref using rel: option for a directory, which is how the separation is achieved. Each cookbook would also have it's own Vagrantfile for testing and metadata dependencies listed.
I guess the problem I'm having is I don't really see any major disadvantage of this myself, so can anyone help inform me why I should use one cookbook per repo instead of managing them in directories like this (but still treating them as essentially separate objects otherwise). All I could think of was it means people might work on two cookbooks in a single branch/commit, but I'm not sure that's necessarily a bad thing.
I should also add that these are all internal cookbooks that are company specific, they would never be shared in the community.
--Yoshi SpendiffDevOps EngineerIndochinoMobile: +1 778 952 2025
Archive powered by MHonArc 2.6.16.