# \- variables vs direct attribute access

**URL:** <https://discourse.chef.io/t/variables-vs-direct-attribute-access/5878>\
**Category:** Chef Infra (archive)\
**Created:** [October 31, 2014, 11:49am UTC](https://discourse.chef.io/t/variables-vs-direct-attribute-access/5878 "2014-10-31T11:49:46Z")\
**Posts on this page:** 13\
**Page:** 1

<div class="post-metadata">

**Author:** ![aL1](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/al1/32/228_2.png) [@aL1](https://discourse.chef.io/u/aL1)\
**Post date:** [October 31, 2014, 11:49am UTC](https://discourse.chef.io/t/variables-vs-direct-attribute-access/5878/1 "2014-10-31T11:49:46Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Tensibai](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/tensibai/32/29_2.png) [@Tensibai](https://discourse.chef.io/u/Tensibai)\
**Post date:** [October 31, 2014, 12:20pm UTC](https://discourse.chef.io/t/variables-vs-direct-attribute-access/5878/2 "2014-10-31T12:20:23Z")

</div>

Variable could be something calculated or logically choosen. The idea is as with mvc models to keep logic away of the template as possible.

Exemple for a jee server you may calculate the heap value from Os type and available ram, it's better to have it inside the recipe than the template.

This way you may set an arbitrary value for rendering (on test to limit the value) instead of cloning the template.

So IMHO not a fail, a valuable feature to use wisely to avoid complex logic in template when it makes sense

---- aL. a écrit ----

> 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

---

<div class="post-metadata">

**Author:** ![Tyler](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/tyler/32/205_2.png) [@Tyler](https://discourse.chef.io/u/Tyler)\
**Post date:** [October 31, 2014, 1:47pm UTC](https://discourse.chef.io/t/variables-vs-direct-attribute-access/5878/3 "2014-10-31T13:47:18Z")

</div>

I don’t have any hard evidence about this, but I suspect that you may get better error messages outside the template.

-T

> On Oct 31, 2014, at 5:20 AM, Tensibai Zhaoying [tensibai@iabis.net](mailto:tensibai@iabis.net) wrote:
> 
> Variable could be something calculated or logically choosen. The idea is as with mvc models to keep logic away of the template as possible.
> 
> Exemple for a jee server you may calculate the heap value from Os type and available ram, it's better to have it inside the recipe than the template.
> 
> This way you may set an arbitrary value for rendering (on test to limit the value) instead of cloning the template.
> 
> So IMHO not a fail, a valuable feature to use wisely to avoid complex logic in template when it makes sense
> 
> ---- aL. a écrit ----
> 
> 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

---

<div class="post-metadata">

**Author:** ![jdunn](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/jdunn/32/1800_2.png) [@jdunn](https://discourse.chef.io/u/jdunn)\
**Post date:** [October 31, 2014, 2:57pm UTC](https://discourse.chef.io/t/variables-vs-direct-attribute-access/5878/4 "2014-10-31T14:57:39Z")

</div>

On Oct 31, 2014, at 9:47 AM, Tyler [tball@getchef.com](mailto:tball@getchef.com) wrote:

> I don’t have any hard evidence about this, but I suspect that you may get better error messages outside the template.

I think that used to be true in old versions of Chef, but not anymore — template errors now show locality.

As others pointed out, if you’re just printing node attributes in the template then it’s kind of a wash either way. But I try to avoid doing really complicated logic in templates, for the sole reason of readability. Interspersing control structures with \<%- and %\> ERB escaping makes my head hurt.

Also, yeah, there are software design arguments (separation of model/controller from view) too.

- Julian

---

<div class="post-metadata">

**Author:** ![Ranjib](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/ranjib/32/1040_2.png) [@Ranjib](https://discourse.chef.io/u/Ranjib)\
**Post date:** [October 31, 2014, 3:32pm UTC](https://discourse.chef.io/t/variables-vs-direct-attribute-access/5878/5 "2014-10-31T15:32:15Z")

</div>

you dont need lazy variable unless you have very specific requirements  
(like the value of that variable depends on another computed attribute at  
compile time) .  
Both style allows nil value, and can be a failure point and there are  
several ways to address that, like chefspec assertion etc. There's an RFC  
on template verification attribute (like guards) which might help in this.

regards  
ranjib

On Fri, Oct 31, 2014 at 4:49 AM, aL. [ocholetrasaleatorias@gmail.com](mailto:ocholetrasaleatorias@gmail.com) 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

---

<div class="post-metadata">

**Author:** ![Lamont\_Granquist\_OLD](https://avatars.discourse-cdn.com/v4/letter/l/7feea3/32.png) [@Lamont\_Granquist\_OLD](https://discourse.chef.io/u/Lamont_Granquist_OLD)\
**Post date:** [October 31, 2014, 5:15pm UTC](https://discourse.chef.io/t/variables-vs-direct-attribute-access/5878/6 "2014-10-31T17:15:15Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Joshua\_Timberman1](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/joshua_timberman1/32/188_2.png) [@Joshua\_Timberman1](https://discourse.chef.io/u/Joshua_Timberman1)\
**Post date:** [October 31, 2014, 6:42pm UTC](https://discourse.chef.io/t/variables-vs-direct-attribute-access/5878/7 "2014-10-31T18:42:32Z")

</div>

This topic came up in the #Chef Infra (archive) irc channel the other day. I said some  
words. Initial question here:

> **[BotBot.me + Startup Resources | Startup Resources](https://startupresources.io/botbot/)**
>
> We are super excited to announce that BotBot.me has been acquired by Startup Resources. BotBot.me was founded with the unique goal of making “IRC logs awesome”. We look forward to serving long time BotBot patrons with similarly engaging content...

Conversation is mixed with some other threads a bit, but ends after about  
30 minutes.

Hope this helps  
Joshua

On Fri, Oct 31, 2014 at 5:49 AM, aL. [ocholetrasaleatorias@gmail.com](mailto:ocholetrasaleatorias@gmail.com) 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

--  
Joshua Timberman, Chef.

---

<div class="post-metadata">

**Author:** ![Lamont\_Granquist\_OLD](https://avatars.discourse-cdn.com/v4/letter/l/7feea3/32.png) [@Lamont\_Granquist\_OLD](https://discourse.chef.io/u/Lamont_Granquist_OLD)\
**Post date:** [October 31, 2014, 7:46pm UTC](https://discourse.chef.io/t/variables-vs-direct-attribute-access/5878/8 "2014-10-31T19:46:44Z")

</div>

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/chef-boneyard/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

---

<div class="post-metadata">

**Author:** ![aL1](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/al1/32/228_2.png) [@aL1](https://discourse.chef.io/u/aL1)\
**Post date:** [November 1, 2014, 11:48pm UTC](https://discourse.chef.io/t/variables-vs-direct-attribute-access/5878/9 "2014-11-01T23:48:40Z")

</div>

Thankyou all guys for your explanations!

My brain was on holidays that day, when i wrote the question, but in some  
way your answers bring some light to the issue!

Putting it all together:

- Avoid logic on template as possible.
- Use variables on template resources when you need logic/pre-proccessing.  
Putting logic on recipe’s side.
- If you give node attribute values directly or computed to the template,  
through variables. Better do it with lazy, so other cookbooks can override  
those attributes later on the runlist.

What do you guys think about my summary here?  
should i put this on a “Best Practices” Chef’s manual? hehe?

Regards!

---

<div class="post-metadata">

**Author:** ![Lamont\_Granquist\_OLD](https://avatars.discourse-cdn.com/v4/letter/l/7feea3/32.png) [@Lamont\_Granquist\_OLD](https://discourse.chef.io/u/Lamont_Granquist_OLD)\
**Post date:** [November 2, 2014, 3:05am UTC](https://discourse.chef.io/t/variables-vs-direct-attribute-access/5878/10 "2014-11-02T03:05:19Z")

</div>

On 11/1/14, 4:48 PM, aL. wrote:

> Thankyou all guys for your explanations!
> 
> My brain was on holidays that day, when i wrote the question, but in  
> some way your answers bring some light to the issue!
> 
> Putting it all together:
> 
> - Avoid logic on template as possible.
> - Use variables on template resources when you need  
> logic/pre-proccessing. Putting logic on recipe's side.
> - If you give node attribute values directly or computed to the  
> template, through variables. Better do it with lazy, so other  
> cookbooks can override those attributes later on the runlist.  
> generally, no. if you want to override an attribute later in the  
> run\_list you want to override it in the attributes files. the node  
> attributes which are used for input should be finalized when you're done  
> parsing attributes files. that is the job of the stages in the  
> chef-client converge which prior to recipe code -- assembling the input  
> state of the node object. the recipes should consume that object and  
> shouldn't need to mutate it.

---

<div class="post-metadata">

**Author:** ![aL1](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/al1/32/228_2.png) [@aL1](https://discourse.chef.io/u/aL1)\
**Post date:** [November 3, 2014, 11:32am UTC](https://discourse.chef.io/t/variables-vs-direct-attribute-access/5878/11 "2014-11-03T11:32:58Z")

</div>

What if you need to modify an attribute only when including a recipe?

i.e. I have a third\_party.rb recipe on my company\_openssh cookbook that  
enables third\_party system group to login via ssh, this is done by adding  
that grop to the [openssh]['allowed\_groups'] attribute. I cant do this on  
attribute files because that way, the group access is always allowed.

i.e. I I want to open 443 on my node firewall only when i enable the  
http\_ssl, by including that recipe on a segurewebserer role

May be im doing somethin wrong, but i think that there are situations where  
you only need some attributes loaded only when a recipe is being applied.  
Not all those attributes being loaded when you include the "default" recipe  
on the node runlist. Or when you need to do some complex logic to calculate  
the attribute value.

Hope i'm explaining my ideas rigth!!

--  
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

On Sun, Nov 2, 2014 at 3:05 AM, Lamont Granquist [lamont@opscode.com](mailto:lamont@opscode.com) wrote:

> On 11/1/14, 4:48 PM, aL. wrote:
> 
> > Thankyou all guys for your explanations!
> > 
> > My brain was on holidays that day, when i wrote the question, but in some  
> > way your answers bring some light to the issue!
> > 
> > Putting it all together:
> > 
> > - Avoid logic on template as possible.
> > - Use variables on template resources when you need  
> > logic/pre-proccessing. Putting logic on recipe's side.
> > - If you give node attribute values directly or computed to the  
> > template, through variables. Better do it with lazy, so other cookbooks can  
> > override those attributes later on the runlist.
> 
> generally, no. if you want to override an attribute later in the  
> run\_list you want to override it in the attributes files. the node  
> attributes which are used for input should be finalized when you're done  
> parsing attributes files. that is the job of the stages in the chef-client  
> converge which prior to recipe code -- assembling the input state of the  
> node object. the recipes should consume that object and shouldn't need to  
> mutate it.

---

<div class="post-metadata">

**Author:** ![Justin\_Dossey](https://avatars.discourse-cdn.com/v4/letter/j/e19b73/32.png) [@Justin\_Dossey](https://discourse.chef.io/u/Justin_Dossey)\
**Post date:** [November 4, 2014, 6:04pm UTC](https://discourse.chef.io/t/variables-vs-direct-attribute-access/5878/12 "2014-11-04T18:04:58Z")

</div>

Another place you'll want to use variables is when you don't want the data  
you're putting into the template to be saved in the node attributes after  
the converge. For example, data from an encrypted data bag shouldn't be  
stored on the node. In that case, only variables will do.

On Mon, Nov 3, 2014 at 3:32 AM, aL. [ocholetrasaleatorias@gmail.com](mailto:ocholetrasaleatorias@gmail.com) wrote:

> What if you need to modify an attribute only when including a recipe?
> 
> i.e. I have a third\_party.rb recipe on my company\_openssh cookbook that  
> enables third\_party system group to login via ssh, this is done by adding  
> that grop to the [openssh]['allowed\_groups'] attribute. I cant do this on  
> attribute files because that way, the group access is always allowed.
> 
> i.e. I I want to open 443 on my node firewall only when i enable the  
> http\_ssl, by including that recipe on a segurewebserer role
> 
> May be im doing somethin wrong, but i think that there are situations  
> where you only need some attributes loaded only when a recipe is being  
> applied. Not all those attributes being loaded when you include the  
> "default" recipe on the node runlist. Or when you need to do some complex  
> logic to calculate the attribute value.
> 
> Hope i'm explaining my ideas rigth!!
> 
> --  
> 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
> 
> On Sun, Nov 2, 2014 at 3:05 AM, Lamont Granquist [lamont@opscode.com](mailto:lamont@opscode.com)  
> wrote:
> 
> > On 11/1/14, 4:48 PM, aL. wrote:
> > 
> > > Thankyou all guys for your explanations!
> > > 
> > > My brain was on holidays that day, when i wrote the question, but in  
> > > some way your answers bring some light to the issue!
> > > 
> > > Putting it all together:
> > > 
> > > - Avoid logic on template as possible.
> > > - Use variables on template resources when you need  
> > > logic/pre-proccessing. Putting logic on recipe's side.
> > > - If you give node attribute values directly or computed to the  
> > > template, through variables. Better do it with lazy, so other cookbooks can  
> > > override those attributes later on the runlist.
> > 
> > generally, no. if you want to override an attribute later in the  
> > run\_list you want to override it in the attributes files. the node  
> > attributes which are used for input should be finalized when you're done  
> > parsing attributes files. that is the job of the stages in the chef-client  
> > converge which prior to recipe code -- assembling the input state of the  
> > node object. the recipes should consume that object and shouldn't need to  
> > mutate it.

--  
Justin Dossey  
Practice Owner  
New Context Services, Inc

---

<div class="post-metadata">

**Author:** ![Lamont\_Granquist\_OLD](https://avatars.discourse-cdn.com/v4/letter/l/7feea3/32.png) [@Lamont\_Granquist\_OLD](https://discourse.chef.io/u/Lamont_Granquist_OLD)\
**Post date:** [November 4, 2014, 8:42pm UTC](https://discourse.chef.io/t/variables-vs-direct-attribute-access/5878/13 "2014-11-04T20:42:16Z")

</div>

Sorry, responding to Alberto, seem to have deleted that e-mail that I  
meant to save to respond to later...

So right now you're calling company\_openssh::third\_party out of the  
run\_list? In that case what you've got a role, and you should have a  
role like role\_third\_party\_access which sets the node attribute. If you  
don't like roles, then you need a role cookbook and put  
role\_third\_party\_access::default (which may be empty) and have an  
attribute file that sets the attribute. When you go with role cookbooks  
you need to have one role per cookbook, burying your roles inside of  
other cookbooks is bad practice (which does mean lots of role cookbooks,  
which does mean lots of git repos if you're doing  
one-git-repo-per-cookbook, which is the tradeoff that you make with role  
cookbooks). If none of that works and you're doing something more  
complicated than setting up a role and have nasty conditional logic  
around the include\_recipe (which I'd argue is still code smell and you  
need to ask yourself why you're doing that), then you should pass state  
between cookbook using the node.run\_state.

On 11/4/14, 10:04 AM, Justin Dossey wrote:

> Another place you'll want to use variables is when you don't want the  
> data you're putting into the template to be saved in the node  
> attributes after the converge. For example, data from an encrypted  
> data bag shouldn't be stored on the node. In that case, only  
> variables will do.
> 
> On Mon, Nov 3, 2014 at 3:32 AM, aL. \<[ocholetrasaleatorias@gmail.com](mailto:ocholetrasaleatorias@gmail.com)  
> [mailto:ocholetrasaleatorias@gmail.com](mailto:ocholetrasaleatorias@gmail.com)\> wrote:
> 
> ```
> What if you need to modify an attribute only when including a recipe?
> 
> i.e. I have a third_party.rb recipe on my company_openssh cookbook
> that enables third_party system group to login via ssh, this is
> done by adding that grop to the [openssh]['allowed_groups']
> attribute. I cant do this on attribute files because that way, the
> group access is always allowed.
> 
> i.e. I I want to open 443 on my node firewall only when i enable
> the http_ssl, by including that recipe on a segurewebserer role
> 
> May be im doing somethin wrong, but i think that there are
> situations where you only need some attributes loaded only when a
> recipe is being applied. Not all those attributes being loaded
> when you include the "default" recipe on the node runlist. Or when
> you need to do some complex logic to calculate the attribute value.
> 
> Hope i'm explaining my ideas rigth!!
> 
> --
> 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
> 
> On Sun, Nov 2, 2014 at 3:05 AM, Lamont Granquist
> <lamont@opscode.com <mailto:lamont@opscode.com>> wrote:
> 
> On 11/1/14, 4:48 PM, aL. wrote:
> 
> Thankyou all guys for your explanations!
> 
> My brain was on holidays that day, when i wrote the
> question, but in some way your answers bring some light to
> the issue!
> 
> Putting it all together:
> 
> - Avoid logic on template as possible.
> - Use variables on template resources when you need
> logic/pre-proccessing. Putting logic on recipe's side.
> - If you give node attribute values directly or computed
> to the template, through variables. Better do it with
> lazy, so other cookbooks can override those attributes
> later on the runlist.
> 
> generally, no. if you want to override an attribute later
> in the run_list you want to override it in the attributes
> files. the node attributes which are used for input should
> be finalized when you're done parsing attributes files. that
> is the job of the stages in the chef-client converge which
> prior to recipe code -- assembling the input state of the node
> object. the recipes should consume that object and shouldn't
> need to mutate it.
> 
> ```
> 
> --  
> Justin Dossey  
> Practice Owner  
> New Context Services, Inc