Second call to a definition fails because of the state of first call.

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Unknown Unknown
  • Resolution: Duplicate
  • Affects Version/s: 0.10.8
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None

Description

I've the following test setup (please ignore the actual work the recipes doing):

A definition under 'test' recipe:

define :test_app, :name => "test" do
    name    = params[:name]

    log "Does /root/#{name}/test exist? #{File.exist?("/root/#{name}/test")}"
    bash "do_something" do
        user    "root"
        group   "root"
        not_if  { File.exist?("/root/#{name}/test") }
        code <<-EOH
            mkdir -p /root/#{name}/test
        EOH
    end
end

Two cookbooks that uses above definition:

test_cookbook_1::default:

include_recipe 'test'
test_app "test_cookbook_1"

test_cookbook_2::default:

include_recipe 'test'
test_app "test_cookbook_2"

And finally a role that uses both cookbooks:
test_role:

run_list(
  "recipe[test_cookbook_1::default]",
  "recipe[test_cookbook_2::default]"
)

When I assign 'test_role' to a node, and run chef-client, 'do_something' resource works properly for 'test_cookbook_1' as expected. However, for 'test_cookbook_2' it's being skipped due to not_if statement, which shouldn't be the case. 

[Thu, 26 Jan 2012 18:00:43 +0000] INFO: Does /root/test_cookbook_2/test exist? false
[Thu, 26 Jan 2012 18:00:43 +0000] DEBUG: Processing bash[do_something] on XXX
[Thu, 26 Jan 2012 18:00:43 +0000] DEBUG: Skipping bash[do_something] due to not_if ruby block

This exact setup was running fine on Chef 9, and started to fail when we upgraded to Chef 10.

When I rename 'do_something' as follows, everything runs as exected:

...
    bash "do_something_for_#{name}" do
        user    "root"
    ...

It looks like Chef10 is keeping state of resources based on the resource name only, which is odd. Any ideas?

Issue Links

duplicates

Bug - A problem which impairs or prevents the functions of the product. CHEF-2812 0.10.4 -> 0.10.6 regression when reloading prior state from resources

  • Unknown - Issue untriaged, priority unassigned or questioned
  • Fix Committed - The fix has been committed to the repository

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Bryan McLellan [Opscode] added a comment -

This is actually expected behavior that started occurring more strictly after 0.10.8. I will discuss this further on CHEF-2812, let's focus the discussion there.

Show
Bryan McLellan [Opscode] added a comment - This is actually expected behavior that started occurring more strictly after 0.10.8. I will discuss this further on CHEF-2812 , let's focus the discussion there.
Hide
Permalink
Bryan McLellan [Opscode] added a comment -

In short though, Chef expects each resource to be uniquely named. This allows you to define a resource once and then act against it without redefining it.

file "service_log" do
  path "/var/log/service_log"
  owner "root"
  group "root"
  mode "0600"
  backup false
  action :nothing
end

# Do some things

file "service_log" do
  action :touch
end

# Do some other things

file "service_log" do
  action :create
  content string_of_some_other_things_output
end
Show
Bryan McLellan [Opscode] added a comment - In short though, Chef expects each resource to be uniquely named. This allows you to define a resource once and then act against it without redefining it. file "service_log" do path "/ var /log/service_log" owner "root" group "root" mode "0600" backup false action :nothing end # Do some things file "service_log" do action :touch end # Do some other things file "service_log" do action :create content string_of_some_other_things_output end

People

  • Assignee:
    Unassigned
    Reporter:
    Hamza Kaya
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: