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

[Lamont Granquist < >]

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:

" type="cite">

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. < " target="_blank"> > 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 < " target="_blank"> > 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