[chef] Re: Chef repo with submodules versus seperate cookbooks, ...

[Brian Fletcher < >]

Hey Stephen,


We have been using a tool called berkshelf. There is lots written about it
online but in summary: It is a dependency management tool for cookbooks.
Each cookbook lives in a single git repository and there is no overall
chef repo. Dependencies are specified in the metadata.rb (as usual).
Berkshelf pulls a cookbooks dependencies down from either: the opscode
site; or a chef server acting as a cookbook repository.

It may not be straight forward migrating from an existing chef-repo to the
berkshelf way of doing things but there are some info online about that
migration too.

http://berkshelf.com/

http://jtimberman.housepub.org/blog/2012/11/19/chef-repository-berkshelf-co
nversion/

https://sethvargo.com/moving-to-individual-cookbooks/


Thanks,

Brian 

On 06/01/2014 07:39, "Steven De Coeyer" 
<
 >
 wrote:

>Hello
>
>I was wondering how most of you manage your chef-repo.
>
>Currently we use one chef repository with all our cookbooks in it and
>some community cookbooks added as submodules.
>As we do not edit the community cookbooks directly, but rather wrap them,
>this is not much an issue. But now we¹d like to opensource some of our
>own cookbooks, which probably means splitting them from our chef
>repository and adding them as submodules as well.
>
>Some problems I foresee with this, are:
> * it¹s not good practice to edit a submodule directly inside the repo
>(or is it?)
> * it¹s not practical to not have all your cookbooks in one place (i.e.
>vagrant expects 1 cookbook path)
> * our chef developers have to take into account to constantly update all
>submodules instead of just one git pull (or we need to complicate git
>usage with git aliases such as ` git config alias.pullall '!git pull &&
>git submodule update --init --recursive¹ `)
>
>Nothing big, nothing that¹s not manageable. It just feels weird and as if
>I¹m missing something.
>
>How do you guys handle this?
>
>Kr.
>S