- From: <
>
- To:
- Subject: [chef] Help with understanding attribute mashing
- Date: Tue, 19 Nov 2013 14:37:32 -0800 (PST)
We're taking advantage of the Elasticsearch community cookbook and decided to
create a wrapper cookbook for it so we can customize the attributes without
touching the community cookbook. To do this, we're just using override
attributes in the wrapper cookbook, but we found some odd behavior.
For example, to override the following attribute in the elasticsearch
cookbook:
default.elasticsearch[:version] = "0.90.2"
We're doing the following in the attributes of the wrapper cookbook:
node.override.elasticsearch[:version] = "0.90.3"
The override works as expected. However, in the following case where another
default attribute assignment references the version attribute i.e.
default.elasticsearch[:filename] =
"elasticsearch-#{node.elasticsearch[:version]}.tar.gz"
The filename attribute gets the default of 0.90.2 instead the override of
0.90.3. There are two workarounds we've found to fix this:
1. Put an include_attribute "elasticsearch_wrapper" in the attributes file of
the community elasticsearch cookbook
2. Place the version override attribute in a role
What I can't figure out is why it works in the role. As far as I understand
it, the override is a higher precedent, be it in an another attribute file or
a
role attribute, so the version assignment should pickup the override attribute
in either method. I'm guessing it has to do with the order of the mashing?
Any help would be appreciated.
Thanks!
-Chris
- [chef] Help with understanding attribute mashing, cwornell, 11/19/2013
Archive powered by MHonArc 2.6.16.