[chef] Re: best practices

[Joshua Timberman < >]

Ohai,

On Jul 16, 2013, at 3:02 AM, Florian Hehlen 
<
 >
 wrote:

> ·         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

Only depends is implemented at this time. The other "dependency" metadata 
elements, suggests, recommends, conflicts, provides, replaces, do not 
actually have an effect on Chef.

For more information, see this ticket:

http://tickets.opscode.com/browse/CHEF-3870

> ·         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 depends on what you mean by uninstallation. Others have touched on this, 
but if the policy of your environment is that certain things should be 
removed, all the core resources in Chef support "negative" actions, where the 
"positive" action is [generally] the default. For example, package has 
:remove, template (or any of the "file" resources) has :delete, service has 
:stop and :disable, etc.

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

I would have a workstation role that has the "workstation things" in the run 
list.

> ·         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.

I think others have covered this, but to be clear:

* "node" - a system that is managed by chef, contains a run list, attributes, 
and environment.
* "client" - an authenticating API client, contains an RSA key pair (server 
stores the public key), and has permissions. The permissions vary based on 
the Chef Server (open source has only "admin" or "non-admin", Opscode's 
Private/Hosted Chef servers have a full role-based access control system).
* "user" - a new feature of Chef 11, users have key pairs like clients, but 
they also have login in the webui, and are representative of human users.

> ·         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 like pinning versions of all cookbooks in a "stable" or "production" type 
of environment using the equality constraint, e.g. "= 2.1.3". I prefer to 
reduce the per-cookbook version constraints as much as possible.

Hope this helps,
Joshua