Node.run_state


#1

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


#2

I think the heading is just wrong. node.run_state is still used (and
we teach it in Chef Intermediate :slight_smile: )

  • Julian

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 ]


#3

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: https://docs.getchef.com/chef_overview_attributes.html ? 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 :slight_smile: )

  • Julian

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 ]


#4

Yes, we (ChefCo) should probably pull the materials from the
intermediate class curriculum to illustrate the use of node.run_state.

  • James
  • Julian

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: https://docs.getchef.com/chef_overview_attributes.html ? 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 :slight_smile: )

  • Julian

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 ]


#5

We are not ChefCo. We are CHEF, or we are Chef Software.

Love,
Adam

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.

  • James
  • Julian

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: https://docs.getchef.com/chef_overview_attributes.html ? 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 :slight_smile: )

  • Julian

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 ]


#6

I have fixed the heading and made a slight change to the structure in that
section:

https://github.com/opscode/chef-docs/commit/1a61184f5f445c1ccde79fd341b243ae3f942ca9

Will follow-up with Julian to get some more context re: how to use
node.run_state for a regular docs update.

james

On Wed, Sep 10, 2014 at 10:54 AM, Adam Jacob adam@getchef.com wrote:

We are not ChefCo. We are CHEF, or we are Chef Software.

Love,
Adam

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.

  • James
  • Julian

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: https://docs.getchef.com/chef_overview_attributes.html ? 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 :slight_smile: )

  • Julian

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 ]


#7

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:

https://docs.getchef.com/essentials_cookbook_recipes.html#node-run-state

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.

  • James
  • Julian

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: https://docs.getchef.com/chef_overview_attributes.html ? 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 :slight_smile: )

  • Julian

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 ]


#8

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:

https://docs.getchef.com/essentials_cookbook_recipes.html#node-run-state

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.

  • James
  • Julian

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: https://docs.getchef.com/chef_overview_attributes.html ? 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 :slight_smile: )

  • Julian

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.


#9

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:

https://docs.getchef.com/essentials_cookbook_recipes.html#node-run-state

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.

  • James
  • Julian

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: https://docs.getchef.com/chef_overview_attributes.html ? 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 :slight_smile: )

  • Julian

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.


#10

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’ => {

  •    'tomcat.debug.enabled' => true,*
    
  •    'tomcat.blah.blah' => 'whatever'*
    }
    
    }
    }
    )
    run_list(…,“recipe[custom-resource]”,“recipe[tomcat]”,…)

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

  •        eval ( "node.override['" + attr.split(".").join("']['") + "']
    

= #{val}" )*
end
end
else
ruby_block “set_attr_#{attr}” do
block do

  •        eval ( "node.override['" + attr.split(".").join("']['") + "']
    

= #{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:

https://docs.getchef.com/essentials_cookbook_recipes.html#node-run-state

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.

  • James
  • Julian

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: https://docs.getchef.com/chef_overview_attributes.html ? 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 :slight_smile: )

  • Julian

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.


#11

You should avoid setting attributes at converge-time using ruby_block
unless you absolutely have to. You are eventually going to have a bad
time in later recipes when you try to use those attributes at compile
time and they don’t work the way you think they will. You’ll have to
use lazy attributes everywhere and
that is code smell that you need to drop those ruby_blocks and move
whatever input prep you need to do before this to compile time.

On Mon Sep 22 22:19:43 2014, DV wrote:

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’ => {

  •    'tomcat.debug.enabled' => true,*
    
  •    'tomcat.blah.blah' => 'whatever'*
    }
    
    }
    }
    )
    run_list(…,“recipe[custom-resource]”,“recipe[tomcat]”,…)

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

  •        eval ( "node.override['" + attr.split(".").join("']['") +
    

“’] = #{val}” )*
end
end
else
ruby_block “set_attr_#{attr}” do
block do

  •        eval ( "node.override['" + attr.split(".").join("']['") +
    

“’] = #{val}” )*
end
end
end
end
end
end