chef - precedence of attributes set on node level

Question

Maybe I missed something in the doc's, but after reading the order that attributes are used when defined in multiple places I don't understand where attributes set at the node level come into the equation

In the 1 to 15 levels of where attributes can be set and overridden, it mentions recipe, environment, role, attribute file but it never seems to mention what happens to attributes defined on a node, say by knife node edit ...

It looks like you can only define attributes of normal type on a node? Normal attributes are only mentioned for priority levels 7 and 8 in the list... attribute files and recipes respectively.

So if I set an attribute on the node that was also defined on the environment and role levels who wins?

Answer 1

The Chef Documentation has a table showing the node attribute precedence. If you edit a node object on the Chef server, or provide node attributes with a JSON file (-j option to chef-solo or chef-client), these are all the "node" level. This is the same level as setting attributes from a recipe. To whit, you can easily set any level of node attribute in a recipe w/ the attribute methods (node.normal, etc) except automatic. On the node object itself (in the Chef Server), you can set default, normal, and override, but not force_default or force_override, nor automatic.

The general guideline we tell people is to always use default attributes:

1. default['thing'] = 'thang' - in a cookbook's attributes file.
2. node.default['thing'] = 'thang' - in a recipe.
3. "default": { "thing": "thang" } - in the node object's JSON
4. default_attributes("thing" => "thang") - in a role (ruby DSL syntax shown).
5. Generally avoid environment set attributes...

And when the need arises for you to set attributes elsewhere at other priorities, you will just know. :)

It may seem arbitrarily over-engineered; originally there were only the node object/recipe and attributes files, and they were just Ruby hashes. Then we added roles, and environments. At some point in there too came the need to set "default" values that could be overridden easily, arbitrarily for various organizational reasons, and now we have the matrix you see today. We're pretty happy with things now, and think it provides the most flexibility for the extremely wide variety of Chef use cases.

Note

This question is not a duplicate of chef versioning - is there an order of precedence - that question pertains to cookbook versions, and this question pertains to node attribute precedence.

Also note that because recipes are Ruby, and executed by the client you can write libraries to manipulate attributes in interesting ways. An example is Chef's whitelist-node-attrs cookbook.