[chef] Re: What to pin in environments?

[Steffen Gebert < >]

Hi Torben, Hi Peter,

thanks for your replies!

This knife-audit only returns a list of cookbooks in use, or also the
used versions? (couldn't find any information about the latter one in
the README).

What you pointed out is what I had in mind and I guess it's atm the
easiest way to to. Having knife-audit to see, which nodes still use old
versions would be really helpful to e.g. make sure that some "bad"
configuration for one software is not isn't in use anywhere anymore.

What still bothers me is the duplicate definition of dependencies in
metadata plus Berksfile. We haven't adopted Berkshelf completely, yet,
but to specify all deps twice smells a bit to me (but there's no other
way, not even with Berks 3, isn't it?).

Thanks for your input!

Yours
Steffen

On 29/01/14 06:02, Peter Donald wrote:
>> And no, it's not that easy anymore to see which versions of the apache
>> cookbook are in use anymore (well it might be searchable via the chef 
>> server
>> API?)
> 
> We use a variant of knife-audit [1] to do this for us and it works well.
> 
>> To me it seems that many people take the route of pinning everything in the
>> environment (e.g. via `berks apply`). To me it seems wrong (or at least as 
>> a
>> smell) to use environments for that, but that's just my view and there 
>> might
>> be some good reasons to do it the other way around. This is just what works
>> well for me...
> 
> I would really like to use the technique you use and we did actually
> migrate towards the approach of only locking down top-level cookbooks
> in the environment files and then lock down supporting cookbooks in
> the top-level cookbooks metadata.
> 
> Unfortunately we repeatedly ran in to the dependency resolver bug in
> Chef 11 (CHEF-3921) which would kill our chef server. So we were
> forced back to locking down everything in environments.
> 
> [1] https://github.com/jbz/knife-audit
> 
>