Attributes at the “normal” level belong to the node and are NOT wiped for each run. All of the other levels belong to an external thing (role, environment, policyfile) so they are wiped and recreated.
Attributes on the node object are only overwritten in the Chef run if there is something in the recipe code which specifically alters that attribute. The node object is both the desired state and current state of the object (although there's future work to split that planned I believe).
Hiera can aggregate multiple hashes or arrays spread between multiple sources into a single attribute.
This is exactly what the chef attribute precedence system does. My understanding is Hiera was written in response to chef’s attributes system, though as a second system it has the benefit of learning from our limitations so it might be more flexible in some ways. In particular Chef has only one attribute level where you can set node-specific values, but these get merged with cookbook/role/environment attributes. Arrays are tricky since sometimes you need them to merge and sometimes override, I would recommend sticking to hashes and then join things yourself.
On Wednesday, October 7, 2015 at 6:36 AM, Fabien Delpierre wrote:
> > Generally you would try to use an existing grouping like a chef environment, role, or policy (if you are using any of those). For single node edits you would do it directly via `knife node edit`. For things that are between the scope of a role and environment, https://github.com/poise/poise-appenv can be a solution.
>
>
> Good to know about knife node edit. Wouldn't any change be overridden at the next chef-client run, though?
> I guess I ought to look into policies, too. I've never used them but I'm not finding much documentation about them. Are we talking about the new-ish Policyfile feature? That I can find documentation about.
Attributes at the “normal” level belong to the node and are NOT wiped for each run. All of the other levels belong to an external thing (role, environment, policyfile) so they are wiped and recreated.
And yeah, policies means policyfiles. We’re still hammering out the exact official terminology.
>
> I was including that when I mentioned "editing the run list" -- of course that works but if I have multiple nodes that use the same set of roles/recipes and I edit one of those roles or recipes, all of them will be affected, which I may not want.
>
> knife node edit does seem like it might help, but I'm concerned that the change wouldn't persist past a chef-client run.
knife node edit by default will only show you things that will be persisted across chef runs: run_list, environment, “normal” attributes.
>
> > As an example I have a recipe which installs a Newrelic agent if a certain attribute is set to true. In the production Chef environment I set the attribute so that all production nodes have this. If I want to use newrelic for a machine outside of production I can set that attribute on the individual node object instead, which could be in any environment.
>
> So that makes sense if you have a recipe that's designed to look for that attribute, but that still seems like it wouldn't accomplish what one might do with Puppet's Hiera.
>
> To use a concrete example, again with attaching YourKit to a JVM process -- like I mentioned, Hiera can aggregate multiple hashes or arrays spread between multiple sources into a single attribute.
This is exactly what the chef attribute precedence system does. My understanding is Hiera was written in response to chef’s attributes system, though as a second system it has the benefit of learning from our limitations so it might be more flexible in some ways. In particular Chef has only one attribute level where you can set node-specific values, but these get merged with cookbook/role/environment attributes. Arrays are tricky since sometimes you need them to merge and sometimes override, I would recommend sticking to hashes and then join things yourself.
> For example, in one YAML file I could have:
> foo::java_opts: "-Xms2g -Xmx2g"
> And in another:
> foo::java_opts: "-agentpath:/opt/yjp/bin/linux-x86-64/libyjpagent.so"
> Then I could invoke this foo::java_opts in a recipe or a template (e.g. for an init script) and Hiera would combine them into one so it produces an init script might read: java -Xms2g -Xmx2g -agentpath:/opt/yjp/bin/linux-x86-64/libyjpagent.so
> When I'm done with YourKit, I can just delete the YAML file that contains those bits and I never have to touch the nodes or the recipe since it only looks for what's in that java_opts attribute and spits it back out.
>
> While so far it doesn't seem like this would be possible in Chef, it does seem like tags would help, if accounted for within a recipe, e.g.:
> node.default['foo']['bar'] = false
>
> if tagged?('bar')
> ruby_block 'enable_bar' do
> block do
> node['foo']['bar'] = true
> end
> end
> end
>
> if node['foo']['bar'] == true
> (do unspeakable things)
> end
My recommendation would be to make the snowflake case part of your cookbook for the non-snowflake case. That way it’s always easy to find out what your system will look like for both cases, and your snowflake configs will be tracked in your git history just like the non-snowflake.
--
Daniel DeLeo
Archive powered by MHonArc 2.6.16.