[chef] Re: [Template] - variables vs direct attribute access

[Lamont Granquist < >]

Here's a concrete example of what I'm talking about from the chef-solo 
cookbooks that are used internal to the chef-server:

https://github.com/opscode/opscode-omnibus/blob/f3d62f3f7272fa54c4682ec16ed7fb131855b924/files/private-chef-cookbooks/private-chef/recipes/opscode-expander.rb#L29-L31

This example still uses the node object to gather inputs for most 
cases, which will get rendered into the hash and passed to the 
template.  It avoids fiddling with the node object directly in the 
template so that the recipe has more control over injecting values into 
the template without having to deal with attribute precedence.   It 
carves out a limited namespace from the node attributes which concerns 
the cookbook, which is probably a best practice and will save typing 
inside of the template itself.  There is also a concrete example here 
of the recipe completely overriding the 
node['private_chef']['opscode-expander']['reindexer'] variable and 
forcing it to false (a good example of avoiding hurting your brain with 
default/override/force_override/force_default attribute precedence 
level issues and just asserting that the code in the cookbook always 
wins because of $RUBY).

So, I'd consider at least variables(node['my_cookbook'].to_hash) to be 
the most future-proof way to access node attributes from templates.  If 
you start hard coding node attributes in templates then at some point 
if you need the recipe code to massage the node attributes for some 
reason then you're either stuck dealing with learning about 
force_default and garbage precedence level issues to try to get the 
node attribute 'right', or you potentially have to rewrite the template 
in order to inject correctly massaged values.

And I can't reiterate too much over the power of avoiding attributes 
once you are in recipe code and just using $RUBY.  You can override 
automatic node attributes with pure ruby (the highest precedence 
level), you can combine attributes and do computed attributes however 
you like.  You can have attributes and search results and whatever 
other inputs and determine whatever precedence for combining them and 
then render those and it will do exactly what your code specifies.  If 
you tie yourself to injecting real node attributes into resources then 
to manipulate those from recipe code you are stuck manipulating node 
attributes from recipes, which typically ends in tears.

On Fri Oct 31 10:15:15 2014, Lamont Granquist wrote:
> A whole lot of the pain involved in attribute precedence levels could
> be avoided if people would construct a variable in their recipes (or
> in a library) that was composed of inputs with whatever precedence
> their logic implied, and then pass that plain ruby variable into
> resources like templates.
>
> Running the node object through everything can be elegant and simple,
> but as soon as you start to fight with attributes and go looking for
> force_default, then you should really consider just rubbing some plain
> ruby on the problem and also introducing multiple node attributes
> rather than trying to make one node attribute do all the work.
>
>
> On Fri Oct 31 04:49:46 2014, aL. wrote:
> > Ohai chefs!
> >
> > I just having a talk with a team member about why or why not use
> > "variables" with lazy or not on template resources.
> >
> > I dont know what is the right way or the "bad practice" way of doing
> > this. Because if you can access attributes directly inside the
> > template, and attributes are compiled an resolved on compile time.
> > ¿Why are you going to want to use variables params on templates?
> >
> > Could be that varibles were just another fail point on the chain, right?
> >
> > Thanks a lot!!!
> > --
> > Si necesitas una máquina para hacer algo y no la compras al final te
> > darás cuenta de que has pagado lo mismo y no tienes la máquina.--Henry
> > Ford
> >
> > Alberto