[chef] Re: Re: Versioned Environments

[Sascha Bates < >]

AMEN. If only I could unsee some of the things I've seen.

Sascha Bates | "> | 612 850 0444 | | |

On 10/15/12 12:43 PM, Adam Jacob wrote:

" type="cite">

On Oct 14, 2012, at 2:38 PM, Peter Donald < "> > wrote:

On Sun, Oct 14, 2012 at 1:32 AM, Bryan Brandau < " target="_blank"> > wrote:

It would be incredibly nice if Chef had the same versioning concept for roles or environments that cookbooks have.  

I wonder if that is really needed. As soon as you version roles is there any real difference between them and cookbooks? Initially our infrastructure included a heap of roles that included attributes and recipes. As we evolved we found the need to version of the attributes and recipes. Slowly our roles evolved to what they are today. So our "graphite" role simply includes the "base_linux_server" role and the "fisg-graphite" recipe and all of our configuration and recipe inclusion occurs within "fisg-graphite". Except for a few of our windows nodes, all of our roles have a 1-to-1 mapping to cookbooks. The role is simply a simplified tag that includes the relevant "role cookbook". 

That way we can version the role cookbooks using the same mechanism we version the other cookbooks

This is what my experience has been as well. You have great places for dynamism in Chef - it's in the cookbooks themselves, and they need to be aware of the various states the infrastructure should be in. Trying to manage that evolution ("I have 3 different desired states") purely through the application of ever more intricate version pinnings is a game that ends with disaster (ask anyone who tries to manage packages this way). 

What I've seen work in the past six months or so, more than once:

* Have environments that are pinned to equality for every cookbook

* Have any logic about what needs to happen dynamically embedded in the cookbooks

Best,

Adam