Running resources & not_if { } qualifier

Hi
When encountering the not_if qualifier, subsequent resource actions are not run?

rvm default_ruby do
action :install
not_if { default_ruby == “system” } # <---- evaluates to 'true’
end

rvm default_ruby do # <---- this is skipped
action :set_default
end

dreamcat4
dreamcat4@gmail.com

On 2 Dec 2010, at 15:13, Dreamcat4 wrote:

Hi
When encountering the not_if qualifier, subsequent resource actions are not run?

rvm default_ruby do
action :install
not_if { default_ruby == "system" } # <---- evaluates to 'true'
end

rvm default_ruby do # <---- this is skipped
action :set_default
end

dreamcat4
dreamcat4@gmail.com

I suspect this is because they both have the same name. I think this will work instead:

rvm default_ruby do
action default_ruby == "system" ? [ :install, :set_default ] : [ :set_default ]
end

On Thu, Dec 2, 2010 at 3:20 PM, Ash Berlin ash_opscode@firemirror.com wrote:

On 2 Dec 2010, at 15:13, Dreamcat4 wrote:

Hi
When encountering the not_if qualifier, subsequent resource actions are not run?

rvm default_ruby do
action :install
not_if { default_ruby == "system" } # <---- evaluates to 'true'
end

rvm default_ruby do # <---- this is skipped
action :set_default
end

dreamcat4
dreamcat4@gmail.com

I suspect this is because they both have the same name. I think this will work instead:

rvm default_ruby do
action default_ruby == "system" ? [ :install, :set_default ] : [ :set_default ]
end

Ah it works - thanks Ash. Heres another way:

actions =
actions << :install unless default_ruby == "system"
actions << :set_default

rvm default_ruby do
action actions
end

So we can do it manually. Sure.

I also wonder if this is a bug in chef? Each time the array of actions
is wiped out and overwritten. Isn't Chef meant to be smart enough to
keep the existing actions when encountering new actions?

dreamcat4
dreamcat4@gmail.com

On 2 Dec 2010, at 15:53, Dreamcat4 wrote:

On Thu, Dec 2, 2010 at 3:20 PM, Ash Berlin ash_opscode@firemirror.com wrote:

On 2 Dec 2010, at 15:13, Dreamcat4 wrote:

Hi
When encountering the not_if qualifier, subsequent resource actions are not run?

rvm default_ruby do
action :install
not_if { default_ruby == "system" } # <---- evaluates to 'true'
end

rvm default_ruby do # <---- this is skipped
action :set_default
end

dreamcat4
dreamcat4@gmail.com

I suspect this is because they both have the same name. I think this will work instead:

rvm default_ruby do
action default_ruby == "system" ? [ :install, :set_default ] : [ :set_default ]
end

Ah it works - thanks Ash. Heres another way:

actions =
actions << :install unless default_ruby == "system"
actions << :set_default

rvm default_ruby do
action actions
end

So we can do it manually. Sure.

I also wonder if this is a bug in chef? Each time the array of actions
is wiped out and overwritten. Isn't Chef meant to be smart enough to
keep the existing actions when encountering new actions?

dreamcat4
dreamcat4@gmail.com

I think its that its not creating a new resource but augmenting the existing one, so the second block is just changing the action for the first one (and keeping the not_if) since they are both "rvm default_ruby" resources.

-ash

Ohai!

On Thu, Dec 2, 2010 at 7:56 AM, Ash Berlin ash_opscode@firemirror.com wrote:

On 2 Dec 2010, at 15:53, Dreamcat4 wrote:

On Thu, Dec 2, 2010 at 3:20 PM, Ash Berlin ash_opscode@firemirror.com wrote:

I also wonder if this is a bug in chef? Each time the array of actions
is wiped out and overwritten. Isn't Chef meant to be smart enough to
keep the existing actions when encountering new actions?

It's a feature. The most common use for this is when you have some
template where several recipes will need to add some content. Then you
do something like this:

Recipe A

template "/etc/something" do
variables(Hash.new) if variables.nil?
variables[:foo] = "bar"
end

Recipe B

template "/etc/something" do
variables(Hash.new) if variables.nil?
variables[:baz] = "qux"
end

It's definitely surprising when you first encounter it, though.

dreamcat4
dreamcat4@gmail.com

I think its that its not creating a new resource but augmenting the existing one, so the second block is just changing the action for the first one (and keeping the not_if) since they are both "rvm default_ruby" resources.

Exactly.

-ash

Dan DeLeo

On Thu, Dec 2, 2010 at 4:45 PM, Daniel DeLeo dan@kallistec.com wrote:

Ohai!

On Thu, Dec 2, 2010 at 7:56 AM, Ash Berlin ash_opscode@firemirror.com wrote:

On 2 Dec 2010, at 15:53, Dreamcat4 wrote:

On Thu, Dec 2, 2010 at 3:20 PM, Ash Berlin ash_opscode@firemirror.com wrote:

I also wonder if this is a bug in chef? Each time the array of actions
is wiped out and overwritten. Isn't Chef meant to be smart enough to
keep the existing actions when encountering new actions?

It's a feature. The most common use for this is when you have some
template where several recipes will need to add some content. Then you
do something like this:

Recipe A

template "/etc/something" do
variables(Hash.new) if variables.nil?
variables[:foo] = "bar"
end

Recipe B

template "/etc/something" do
variables(Hash.new) if variables.nil?
variables[:baz] = "qux"
end

It's definitely surprising when you first encounter it, though.

dreamcat4
dreamcat4@gmail.com

I think its that its not creating a new resource but augmenting the existing one, so the second block is just changing the action for the first one (and keeping the not_if) since they are both "rvm default_ruby" resources.

Exactly.

-ash

Dan DeLeo

I too would be surprised to be the first person to notice this. Does
this mean I should be changing my resource somehow? Ie to be creating
a new resource in each instance?

Thanks

dreamcat4
dreamcat4@gmail.com

On Thu, Dec 2, 2010 at 9:12 AM, Dreamcat4 dreamcat4@gmail.com wrote:

I too would be surprised to be the first person to notice this. Does
this mean I should be changing my resource somehow? Ie to be creating
a new resource in each instance?

Yep. Resources are keyed by type and name (the first argument, before
the do...end block). So:

package "foo"
service "foo"

are different, as are:

package "foo"
package "bar"

but

package "foo"
package "foo"

are the same, and any parameters you set on the second one will
modify/override the first one.

Dan DeLeo

Thanks

dreamcat4
dreamcat4@gmail.com