[chef] Re: Re: Re: Re: Re: Re: Re: Environments vs. Metadata vs. Policyfile for locking cookbook dependencies

[Daniel DeLeo < >]

On Friday, June 20, 2014 at 3:56 PM, Maxime Brugidou wrote:

> The requirement of having the entirety of the chef repo as deployable 
> artifact comes naturally when you have it in git. You want to ship that 
> specific branch/commit.
> This actually led us to have multiple chef repos (and chef servers, called 
> "perimeters") because we needed to deal with large teams and different 
> deployments.
> So basically we are enforcing the policy system to the extreme by having 
> one chef repo/server (we currently have 6 of them (+preprods) and try to 
> not add more unless a team is dedicated to maintain it).

No. We at CHEF still have some stuff in the single chef-repo format, and lots 
of users do too. Single repo per cookbook is nice, but it can be hard to get 
there without disrupting everyone’s productivity (assuming you want to get 
there as an end goal, which maybe you don't). We’ll be paying special 
attention to making the policy stuff usable with a single chef repo.
  
> I don't see how we could work it out with proper git workflow if we didn't 
> split the repos. The best solution would have been using chef organizations 
> (not open source) to have a single chef server.
> The current workflow is actually very satisfying, we just have a simple 
> internal tool using former knife-essentials to sync all objects from git to 
> chef. We could have gone with pure role cookbooks and locking all versions 
> but that seemed way too dangerous. We needed the guarantee of segregating 
> at least perimeters.

Where does the danger come from? Are you using roles? Uploading cookbooks 
without freezing them? The policyfile guarantees you’ll have exactly the same 
cookbooks by assigning them identifiers based on the hash of the content in 
them. And it guarantees you’ll have exactly the same run list by “baking in” 
roles when the policyfile is compiled into the policyfile lock. Then you 
promote the lock through whatever stages you have in your lifecycle (e.g., 
integration test, dev, stage, prod, whatever).
  
> We never encounter dependency management issue. Just need upgrading the 
> Berksfile.lock.




--  
Daniel DeLeo