Matthew,
Thanks! After thinking about it and re-reading docs I think your suggestion
got me to realize why I can't just set node.run_state the way I can set
node.normal:
>run_state is an empty Hash that is always discarded at the end of the
chef-client run.
So I have to treat it as empty hash instead of as node's attributes hash,
and also, it can't be used to modify cookbook behavior (because
node.run_state doesn't get merged with node.normal attributes).
So, for my recipe to override attributes at recipe level, I have to
use node.override['something']
= value. That way I get to override the value, yet the override doesn't
get saved to node object like it would with node.normal['something'] =
value.
P.S. The use case for this recipe is to let users override any cookbook
attributes on per-environment, per-role basis. For example - enabling
Tomcat debugging on particular set of webapps in particular environment.
Normally this would require doing "knife node edit" or creating a special
recipe to set attributes.
Here's working code snippets:
Goal: set node['tomcat']['debug']['enabled]=true and
*node['tomcat']['blah']['blah']='whatever'
*on my-webapp-1 hosts in qa-1 environment.
my-webapp-1.rb:
name "my-webapp-1"
description "Role for my webapp 1"
default_attributes(
'custom-resource' => {
'env_attributes' => {
'qa-1' => {
Then the Ruby block overrides Tomcat cookbook's attributes at run time:
cookbooks/custom-resource/attributes/default.rb
default["custom-resource"]["env_attributes"] = Hash.new
cookbooks/custom-resource/default.rb
node["custom-resource"]["env_attributes"].each do |env, attrs|
if env == node[:environment][:name]
Chef::Log.info("Setting env_attributes for #{env}...")
attrs.each do |attr,val|
Chef::Log.info("Setting attribute #{attr} to #{val}")
if val.instance_of? String
ruby_block "set_attr_#{attr}" do
block do
= #{val}" )*
end
end
else
ruby_block "set_attr_#{attr}" do
block do
= #{val}" )*
end
end
end
end
end
end
- We store our environment name in node['environment']['name'], it may be
different for you.
Some would suggest that this recipe should catch NoMethodError and handle
things (so that undefined attributes can be set) but I'd rather let it fail
so the user knows he/she is setting an undefined attribute instead of
overriding a defined one.
On Mon, Sep 22, 2014 at 7:06 PM, Matthew Moretti werebus@gmail.com wrote:
This sort of error pops up when you try to set an attribute deeper than is
currently defined. That is if node.run_state['some'] or
node.run_state['some']['dynamic'] or
node.run_state['some']['dynamic']['attribute'] doesn’t exist (is nil)
then you can’t set it’s sub-values.
Since this is a temporary state value, is there any reason to burry it so
deep? Probably this would be sufficient:
ruby_block "set_attr_#{attr}" do
block do
node.run_state['a_temporary_value_of_some_kind''] = val
end
end
Hope that helps.
Matt Moretti
On Mon, Sep 22, 2014 at 9:51 PM, DV vindimy@gmail.com wrote:
Maybe you guys can help me out really quick. I was very happy to have
found out about node.run_state because we just happened to need to set
some runtime attributes set dynamically thru a recipe.
But, the following code works, and the one below it doesn't.
ruby_block "set_attr_#{attr}" do
block do
eval ( "node.*normal*['some']['dynamic']['attribute']['name']
= #{val}" )
end
end
(attribute gets stored in node object, do not want this permanence)
versus:
ruby_block "set_attr_#{attr}" do
block do
eval ( "node.*run_state*['some']['dynamic']['attribute']['name']
= #{val}" )
end
end
(doesn't work, but do want).
The error we get for the 2nd block:
NoMethodError: ruby_block[set_attr_zenoss.enabled]
(custom-resource::env_attributes line 24) had an error: NoMethodError:
undefined method `=' for nil:NilClass
The reason we're putting this into ruby block is because "
['some']['dynamic']['attribute']['name']" part needs to be changeable
thru attribute (in effect, setting node['something']['or']['other'] =
some_value for the duration of chef-client run).
Is there anything we can do about this? Is there anything else close to
node.run_state that we can use?
On Wed, Sep 10, 2014 at 2:53 PM, James Scott jamescott@opscode.com
wrote:
OK, so the release notes/breaking changes topic is updated:
https://docs.getchef.com/breaking_changes_chef_11.html#node-run-state-seen-recipes-replaced
and there's an example of using node.run_state here:
About Recipes
james
On Wed, Sep 10, 2014 at 10:51 AM, Julian C. Dunn jdunn@aquezada.com
wrote:
Yes, we (ChefCo) should probably pull the materials from the
intermediate class curriculum to illustrate the use of node.run_state.
On Wed, Sep 10, 2014 at 10:46 AM, John Warren j0hnwarr3n@gmail.com
wrote:
Thanks for the reply. The apparent lack of documentation of
node.run_state
is a bit troubling: the link below is the first Google hit when I
search for
"chef node run_state". Is there any documentation that discusses
node.run_state in depth, the way node attributes are discussed, for
instance
here: About Attributes ? You
have me
convinced that node.run_state is kosher, but the people who review my
code
and have already -1'd it (citing the reference below) may not be as
easily
swayed. Having official documentation that refutes the erroneous
heading in
the referenced official release notes would be most helpful in making
my
case that my code (at least as far as the use of node.run_state goes)
is up
to spec.
Thanks,
John
-----Original Message----- From: Julian C. Dunn
Sent: Wednesday, September 10, 2014 9:54 AM
To: chef@lists.opscode.com
Subject: [chef] Re: node.run_state
I think the heading is just wrong. node.run_state is still used (and
we teach it in Chef Intermediate 
)
On Wed, Sep 10, 2014 at 9:41 AM, John Warren j0hnwarr3n@gmail.com
wrote:
The following section in the documentation for Chef client 11
appears to
be
a source of some confusion:
https://docs.getchef.com/breaking_changes_chef_11.html#node-run-state-replaced
The heading of the section would seem to indicate that node.run_state
should
not be used at all anymore, while the section text seems to
reference only
node.run_state[:seen_recipes] as no longer being valid. Can I get
some
clarification on what the status of node.run_state is in terms of
having
been “replaced” as a whole or in part?
Thanks,
John
--
[ Julian C. Dunn jdunn@aquezada.com * Sorry, I'm ]
[ WWW: http://www.aquezada.com/staff/julian * only Web 1.0 ]
[ gopher://sdf.org/1/users/keymaker/ * compliant! ]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9 ]
--
[ Julian C. Dunn jdunn@aquezada.com * Sorry, I'm ]
[ WWW: http://www.aquezada.com/staff/julian * only Web 1.0 ]
[ gopher://sdf.org/1/users/keymaker/ * compliant! ]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9 ]
--
Best regards, Dmitriy V.
--
Best regards, Dmitriy V.