Kevin,If you treat roles as implementation, then you will need to start versioning them.If you treat roles as interface, as a declaration of intent only, and remove all implementation from them, then you will need to implement them with an implementation cookbook, so to speak. The role will not need to be versioned itself; only the implementation cookbook will need to be versioned.Cheers,JayOn Tue, Nov 20, 2012 at 1:31 PM, Kevin Christen < " target="_blank"> > wrote:
Here's a scenario for the use of roles and cookbooks in Chef server that confuses me. I'd like to know how the community handles this situation. Imagine that I have a cookbook "foo" at version 1.0.0 with a single recipe "bar". I define a role "foo_host" with "recipe[foo::bar]" in its run_list.Now imagine that I improve the "foo" cookbook by adding a "baz" recipe and increment it's version number to 1.1.0. What do I do with the role? If I add the new recipe to the "foo_host" run_list, I will break any nodes that won't use the latest version of the cookbook because of an environment version constraint. I can only think of a few solutions:
- Version the role through its name. In other words, leave "foo_host" alone and create a "foo_host_1" role with both recipes in its run_list.
- Run separate versions of chef server for each environment, as mentioned here. Update the role in only those servers who's environment will pick up the latest version of the cookbook.
- Don't use a role for this purpose. Instead, define a separate, versioned "wrapper" cookbook as described by Bryan Berry here.
Is there a community consensus on how to deal with this situation?Thanks,Kevin Christen
Archive powered by MHonArc 2.6.16.