[chef] Re: Re: best practices

["Eric G. Wolfe" < >]

For uninstallation, I like the idea of an "undo" recipe.  For example, RHEL flavors tend to install NFS as part of the base installation.  When I set out to do the nfs cookbook, I was sure to create an "nfs::undo" run-once recipe which will clean up that annoyance.  The annoyances cookbook is another good example of reversing an undesired state on a managed node.

I think the idea of an undo recipe should be to step backwards logically through the installed/running pattern.  Run-once capability is a nice thing to have for a "kickstart" type of role.  For example, I may want to undo nfs on every fresh installation.  However, I don't want the "nfs::undo" recipe to permanently exist in the run_list and reverse the state of an actual NFS server either.

Eric G. Wolfe
Senior Linux Administrator,
IT Infrastructure Systems
--------------------------------------
Marshall University Computing Services
Drinko Library 428-K
One John Marshall Dr.
Huntington, WV 25755
Phone: 304.942.3970
Email: 
 
 ">
 

You will be recognized and honored as a community leader.

On 07/16/2013 12:50 PM, Matthew Moretti wrote:

" type="cite">

I'll take a stab at a few of these. Answers inline.

On Tue, Jul 16, 2013 at 5:02 AM, Florian Hehlen < " target="_blank"> > wrote:

Hi all,

 

I am looking for some tips on chef best practices and having a hard time finding anything other than highly focused docs and  tutorials on the web. Here are some of the issues I am struggling with:

·         What granularity is best for recipes?  When does it make sense to use some of the more complex ideas like depends, replaces, recommends/suggest, etc

Granularity is really up to you, but I think it's better to not have a given cookbook or recipe do too much.  As far as the various cookbook metadata fields, I don't think I've ever seen any of them other than "depends" used.  Do declare your dependencies, though.

·         How to handle uninstallation? As different cookbooks, or as a different recipe, or as something that will be done under the covers by a replacement recipe…

It kind of depends on what your end goal is.  I've never had the need to specifically remove a package in order to get to by desired end-state.  If you do need that, I'd put 

·         How to structure roles in a generic and useful way for workstations and servers.

Again, this depends on your needs.  Roles are generally used to group a set of related recipes, but some folks don't use them at all.

·         I find that there is a certain amount of overlap in definition between node, client, and user. In fact bootstrapping creates a node and a client for each machine. Is there a good way to think about how these 3 relate to each other.

So, nodes are "the thing you're configuring" - they generally correspond to "servers" or "ec2 instances".  Clients are "how you authenticate to the Chef Server", and you're right: if you're using a Chef server, they'll pretty much always be one-to-one (i think it's technically possible to do otherwise, but I wouldn't).  Users are really just a special kind of client that also has a password for the WebUI - they generally correspond to people (like you).

·         How to best manage recipe versioning using versions, environments, version constraints, etc. I am specifically wondering about being able to upload recipes that are being developed and tested without the fear that they will end up in production. I would like to stay away from having to manage 2 instances of chef. 

 

I realise that this is a whole lot of stuff in one email… this is a list of questions that has been growing in the last few weeks as I explore and plan for chef in our environment.

 

Cheers,

Flo

LEGAL DISCLAIMER
This communication and any attached documents are strictly confidential and/or legally privileged and they may not be used or disclosed by someone who is not a named recipient. If you have received this electronic communication in error please notify the sender by replying to this electronic communication inserting the word "misdirected" as the subject and delete this communication from your system.

Hope that helps,

Matt Moretti