[chef] Re: Re: Re: Puppet+Hiera vs. Chef, or handling the occasional special snowflake server

[Daniel DeLeo < >]

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