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. <firstname.lastname@example.org
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
On Sun, Nov 2, 2014 at 3:05 AM, Lamont Granquist
<email@example.com <mailto:firstname.lastname@example.org>> 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
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.
New Context Services, Inc