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:
- description of the configuration that should be applied to the node
- passing values between recipes
- 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
dennis.benzinger@sap.com
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.