Attributes - Learning Chef - page 178

[["set_unless_enabled?", false],
["default", "1.1.1.1"],
["env_default", :not_present],
["role_default",
:not_present],
["force_default", :not_present],
["normal", :not_present],
["override", :not_present],
["role_override", :not_present],
["env_override", :not_present],
["force_override", :not_present],
["automatic", "10.0.2.15"]]
...
From here, you could sort out that the node['ipaddress'] attribute was set to the value of
"10.0.2.15" at the automatic precedence level and set to the value "1.1.1.1" at the de-
fault precedence level. So Chef did register that you set the value to "1.1.1.1" , but the
override took precedence.
NOTE
You might notice that there are more precedence levels in the node.debug_level() out-
put than we have discussed so far in this topic. We are intentionally simplifying attribute
precedence in this topic. If you follow the guideline of using default precedence, unless
there is a specific need, you rarely have to deal with the full complexity of attribute pre-
cedence with basic Chef cookbook code.
A lot of the complexity of attributes arose as the precedence feature was introduced in
Chef and cookbooks needed to be written to be backward-compatible with older versions.
With Chef 11, most cookbooks follow the default precedence guideline.
If you'd like to learn more about the details of attribute precedence, refer to the aforemen-
tioned Customizing Chef .
Debugging when an attribute is set in two or more places at the same precedence level is a
little more difficult to trace, but still not too complicated. You just need to sprinkle
node.debug_value() statements before and after include_recipe calls.
For example, say we didn't know that the motd-attributes::message recipe set
node.default['motd-attributes']['message'] . We could figure this out by sprinkling