[chef] Re: Cookbook Attributes Best Practices/Guidelines ?

[Lamont Granquist < >]

Its better to use LWRP/HWRPs in library cookbooks over having recipes 
with attributes as the API, see the new mysql or httpd cookbooks.    
This is a significantly better approach since it doesn't force 
attributes as APIs on the consumer of the library cookbook.  The 
consumer may choose to hardcode the values, put them in attributes, pull 
them from a databag, get them from search, or do something even more 
complicated to populate the values sent to the LWRP which is much more 
flexible.  If you write an LWRP that takes a property that is an IP/DNS 
name or array of them rather than hard coding a search result in your 
cookbook then you're not imposing your own search-based structure on the 
cookbook (and the cookbook will be usable by chef-solo and with simple 
installations just by hardcoding "127.0.0.1").

So, the simplest solution to attributes is to just stop using them 
entirely.

Then when you want to introduce attributes for your site do so in a way 
that makes sense for you and structure them around your roles and role 
cookbooks and the data that you actually want searchable via search.

The node.run_state should be used for cookbooks that just need to talk 
to other cookbooks (variables declared in one recipe aren't visible in 
another recipe, so if you're only trying to solve that problem, then the 
node.run_state is better for 'global' state rather than an attribute -- 
with the security benefit that if you're putting sensitive information 
like passwords into that state then it also will not get sent back to 
the server with the node data).

Generally there are three ways that attributes are used:

1. description of the configuration that should be applied to the node
2. passing values between recipes
3. saving values for search at the end of the run

Generally you want to stick with using attributes for #1 and #3. You 
should use the node.run_state to solve #2.  If you are writing to 
attributes in recipe code you're probably better off using the run_state 
(unless you're computing something for the purposes of publishing with 
the node data which is case #3).  For case #1 you should consider what 
you're building with attributes to be a *document* which is going to be 
fully compiled by the time the attributes parsing pass is done and 
should fully describe the desired state of the node.  That document 
should then be considered to be immutable when its consumed by the 
recipes (of course except if you're writing out the result of some 
computation to publish back to search for #3).

That is going to be a best practice which will let you use attributes 
simply and avoid 90% of the complexity around them so that you won't 
need to become an expert in all the different precedence levels and why 
force_default is there.

And +1 on trying to avoid worrying about deep merging and avoiding arrays.

On 07/24/2015 04:02 AM, Benzinger, Dennis wrote:
> Hello List,
>
> what are some good websites or presentations about best practices/guidelines
> for attributes in cookbooks?
>
> For example about:
> - Naming of the attribute files
> - Naming of the attributes themselves
> - Arrays vs. hashes
> - And especially interesting for me:
>    
>    When to use node.run_state instead of an attribute?
>
>    I've seen cookbooks which put every variable in an attribute even if it is 
> used
>    only internally. Wouldn't it be better to use node.run_state in this case? 
> At
>    least as long as you don't have to store it between Chef runs.
>
>
> Thanks,
> Dennis Benzinger | hybris
>
> --
> Dennis Benzinger
> IT Architecture Senior Specialist
> hybris Cloud Services
>
>  
>
> hybris GmbH
> Nymphenburger Straße 86
> 80636 München, Germany
> Fax +49 89 890 65 555
> www.hybris.com
> hybris GmbH, Nymphenburger Str. 86, 80636 München, Deutschland.
> Geschäftsführer: Ariel F. Lüdi, Carsten Thoma, Michael Zips.
> Amtsgericht München, HRB 124384.