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

[Daniel DeLeo < >]

On Wednesday, October 7, 2015 at 12:58 PM, Fabien Delpierre wrote:

> > 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).
>  
> Alright, so I never bothered to look up normal attributes, but that makes 
> sense then. Is it correct that, by default, knife node edit will set 
> normal-level attributes, and if you want to set something at a different 
> level as a one-off, you can use the -a flag?
>  
> > > 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.
>  
>  
> I guess I was confused. Admittedly I haven't had to worry about merging 
> hashes in Chef attributes, but I thought that attributes were overwritten 
> by sources higher in the food chain, period. I now see that's not the case 
> with hashes: https://docs.chef.io/attributes.html#about-deep-merge
> Well, good to know!
>  
> So I guess I'm still trying to figure out if key Hiera functionality is 
> easily achieved in Chef or if you just have to use a totally different 
> approach. The examples I used kind of steered the conversation in the wrong 
> direction (although valuable things were still learned!).
> Concretely, here's how I might have Hiera set up:
> ---
> :backends:
> - yaml
> :yaml:
> :datadir: /etc/puppet/hiera
> :hierarchy:
> - %{::region}/%{::fqdn}
> - %{::region}/%{env}
> - %{::region}/common
> - global
>  
> That means I can store a whole bunch of attributes in 
> /etc/puppet/hiera/global.yaml that will apply to all nodes.
> Attributes stored in /etc/puppet/hiera/us-east/common.yaml can add to or 
> override attributes stored in global.yaml.
> Attributes stored in /etc/puppet/hiera/us-west/common.yaml will not 
> interact/-fere with the ones in us-east.
> Attributes stored in /etc/puppet/hiera/us-west/%{env}.yaml will be applied 
> to all nodes in us-west whose names match %{env} (e.g. if %{env} = foo then 
> all nodes called foo01, foo02, foo03, etc. will be matches.  
> Attributes stored in /etc/puppet/hiera/us-west/%{::fqdn}.yaml will only be 
> applied to the particular node named by its FQDN (that special snowflake I 
> was talking about) and will override attributes (or merge, if they are 
> arrays or hashes) that are stored lower in the hierarchy.
>  
> I suppose that one way this can be achieved with Chef is with a set of 
> roles, so I'd have common, us-east, us-west and <fqdn> roles, but it gets 
> dicey with my %{env} thing above where settings can be applied to all nodes 
> with similar names (I used 'web' in my example but it could be 'foo', 
> 'bar', 'asdf'...). I don't know how I can do that with Chef as easily as 
> with Hiera. Can I?
Roles can also override other roles, so you can just set default attributes 
in roles and put all of the ones you need the run lists of the appropriate 
nodes. That said, you might just be better off making a cookbook that has 
only attributes files, and put a ruby statement like `return unless 
node.something == “some value”` at the top of each one. Then you can control 
which attributes get applied on whatever axis you like.
  

--  
Daniel DeLeo