0.10.4 -> 0.10.6 regression when reloading prior state from resources

Details

  • Type: Bug Bug
  • Status: Fix Committed Fix Committed
  • Priority: Unknown Unknown
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 10.18.0
  • Component/s: Chef Solo
  • Labels:
    None
  • Environment:

    Fedora 15
    chef-solo
    ruby 1.8.7 (2011-06-30 patchlevel 352) [x86_64-linux]

Description

Description:

Looping over a resource (i.e. an execute resource), changing the parameters but not the identifier, prints out a somewhat cryptic message about the state of the resource. 

[Wed, 14 Dec 2011 22:40:32 +0000] DEBUG: Setting execute[touch_file] to the state of the prior execute[touch_file]

I noticed this several weeks ago (with 0.10.4), but as it still produced the desired effect, I didn't change anything. Now, with Chef 0.10.6, the only the first parameter set is applied. Although the resource appears to converge multiple times, it does not use the subsequent parameter sets. Also, removing the 'not_if' (see below).

Both behaviors makes sense. Perhaps raising an exception instead of resetting the state would be appropriate.

Thanks!

Recipe:

files = %w(one.txt two.txt)
	files.each do |filename|
	  execute "touch_file" do
	    command "touch /tmp/#{filename}"

	    # It works without this 'not_if'
	    not_if "ls /tmp/#{filename}"
	  end
	end

	execute "ls_file" do
	  command "ls /tmp/two.txt"
	end

10.4 Run (successful exit)

[root@cionebox chef]# chef-solo -j broken.json -l debug
	[Wed, 14 Dec 2011 22:40:31 +0000] INFO: *** Chef 0.10.4 ***
	[Wed, 14 Dec 2011 22:40:32 +0000] DEBUG: Building node object for cionebox
	[Wed, 14 Dec 2011 22:40:32 +0000] DEBUG: Extracting run list from JSON attributes provided on command line
	[Wed, 14 Dec 2011 22:40:32 +0000] INFO: Setting the run_list to ["recipe[onebox::broken]"] from JSON
	[Wed, 14 Dec 2011 22:40:32 +0000] DEBUG: Applying attributes from json file
	[Wed, 14 Dec 2011 22:40:32 +0000] DEBUG: Platform is fedora version 15
	[Wed, 14 Dec 2011 22:40:32 +0000] INFO: Run List is [recipe[onebox::broken]]
	[Wed, 14 Dec 2011 22:40:32 +0000] INFO: Run List expands to [onebox::broken]
	[Wed, 14 Dec 2011 22:40:32 +0000] INFO: Starting Chef Run for cionebox
	[Wed, 14 Dec 2011 22:40:32 +0000] DEBUG: No chefignore file found at /opt/titan/chef/cookbooks/chefignore no files will be ignored
	[Wed, 14 Dec 2011 22:40:32 +0000] DEBUG: Loading cookbook endpoint's library file: /opt/titan/chef/cookbooks/endpoint/libraries/chef_ext.rb
	[Wed, 14 Dec 2011 22:40:32 +0000] DEBUG: Loading cookbook endpoint's library file: /opt/titan/chef/cookbooks/endpoint/libraries/bindings.rb
	[Wed, 14 Dec 2011 22:40:32 +0000] DEBUG: Loading cookbook yggdrasil's providers from /opt/titan/chef/cookbooks/yggdrasil/providers/event.rb
	[Wed, 14 Dec 2011 22:40:32 +0000] DEBUG: Loaded contents of /opt/titan/chef/cookbooks/yggdrasil/providers/event.rb into a provider named yggdrasil_event defined in Chef::Provider::YggdrasilEvent
	[Wed, 14 Dec 2011 22:40:32 +0000] DEBUG: Loading cookbook yggdrasil's resources from /opt/titan/chef/cookbooks/yggdrasil/resources/event.rb
	[Wed, 14 Dec 2011 22:40:32 +0000] DEBUG: Loaded contents of /opt/titan/chef/cookbooks/yggdrasil/resources/event.rb into a resource named yggdrasil_event defined in Chef::Resource::YggdrasilEvent
	[Wed, 14 Dec 2011 22:40:32 +0000] DEBUG: Node cionebox loading cookbook graphite's attribute file /opt/titan/chef/cookbooks/graphite/attributes/graphite.rb
	[Wed, 14 Dec 2011 22:40:32 +0000] DEBUG: Loading cookbook munin's definitions from /opt/titan/chef/cookbooks/munin/definitions/munin_plugin.rb
	[Wed, 14 Dec 2011 22:40:32 +0000] DEBUG: Loading Recipe onebox::broken via include_recipe
	[Wed, 14 Dec 2011 22:40:32 +0000] DEBUG: Found recipe broken in cookbook onebox
	[Wed, 14 Dec 2011 22:40:32 +0000] DEBUG: Setting execute[touch_file] to the state of the prior execute[touch_file]
	[Wed, 14 Dec 2011 22:40:32 +0000] DEBUG: Loading from cookbook_path: /opt/titan/chef/cookbooks
	[Wed, 14 Dec 2011 22:40:32 +0000] DEBUG: Converging node cionebox
	[Wed, 14 Dec 2011 22:40:32 +0000] DEBUG: Processing execute[touch_file] on cionebox
	[Wed, 14 Dec 2011 22:40:32 +0000] INFO: Processing execute[touch_file] action run (onebox::broken line 3)
	[Wed, 14 Dec 2011 22:40:32 +0000] DEBUG: Executing ls /tmp/one.txt
	[Wed, 14 Dec 2011 22:40:32 +0000] DEBUG: ---- Begin output of ls /tmp/one.txt ----
	[Wed, 14 Dec 2011 22:40:32 +0000] DEBUG: STDOUT: /tmp/one.txt
	[Wed, 14 Dec 2011 22:40:32 +0000] DEBUG: STDERR: 
	[Wed, 14 Dec 2011 22:40:32 +0000] DEBUG: ---- End output of ls /tmp/one.txt ----
	[Wed, 14 Dec 2011 22:40:32 +0000] DEBUG: Ran ls /tmp/one.txt returned 0
	[Wed, 14 Dec 2011 22:40:32 +0000] DEBUG: Skipping execute[touch_file] due to not_if
	[Wed, 14 Dec 2011 22:40:32 +0000] DEBUG: Processing execute[touch_file] on cionebox
	[Wed, 14 Dec 2011 22:40:32 +0000] INFO: Processing execute[touch_file] action run (onebox::broken line 3)
	[Wed, 14 Dec 2011 22:40:32 +0000] DEBUG: Executing ls /tmp/two.txt
	[Wed, 14 Dec 2011 22:40:32 +0000] DEBUG: ---- Begin output of ls /tmp/two.txt ----
	[Wed, 14 Dec 2011 22:40:32 +0000] DEBUG: STDOUT: /tmp/two.txt
	[Wed, 14 Dec 2011 22:40:32 +0000] DEBUG: STDERR: 
	[Wed, 14 Dec 2011 22:40:32 +0000] DEBUG: ---- End output of ls /tmp/two.txt ----
	[Wed, 14 Dec 2011 22:40:32 +0000] DEBUG: Ran ls /tmp/two.txt returned 0
	[Wed, 14 Dec 2011 22:40:32 +0000] DEBUG: Skipping execute[touch_file] due to not_if
	[Wed, 14 Dec 2011 22:40:32 +0000] DEBUG: Processing execute[ls_file] on cionebox
	[Wed, 14 Dec 2011 22:40:32 +0000] INFO: Processing execute[ls_file] action run (onebox::broken line 9)
	[Wed, 14 Dec 2011 22:40:32 +0000] INFO: execute[ls_file] sh(ls /tmp/two.txt)
	/tmp/two.txt
	[Wed, 14 Dec 2011 22:40:32 +0000] INFO: execute[ls_file] ran successfully
	[Wed, 14 Dec 2011 22:40:32 +0000] INFO: Chef Run complete in 0.48186 seconds
	[Wed, 14 Dec 2011 22:40:32 +0000] DEBUG: Cleaning the checksum cache
	[Wed, 14 Dec 2011 22:40:32 +0000] INFO: Running report handlers
	[Wed, 14 Dec 2011 22:40:32 +0000] INFO: Resources updated this run:
	[Wed, 14 Dec 2011 22:40:32 +0000] INFO:   execute[ls_file]
	[Wed, 14 Dec 2011 22:40:32 +0000] INFO: Report handlers complete
	[Wed, 14 Dec 2011 22:40:32 +0000] DEBUG: Exiting

10.6 Run (unsuccessful exit)

[root@cionebox chef]# chef-solo -j broken.json -l debug
	[Wed, 14 Dec 2011 22:43:03 +0000] INFO: *** Chef 0.10.6 ***
	[Wed, 14 Dec 2011 22:43:04 +0000] DEBUG: Building node object for cionebox
	[Wed, 14 Dec 2011 22:43:04 +0000] DEBUG: Extracting run list from JSON attributes provided on command line
	[Wed, 14 Dec 2011 22:43:04 +0000] INFO: Setting the run_list to ["recipe[onebox::broken]"] from JSON
	[Wed, 14 Dec 2011 22:43:04 +0000] DEBUG: Applying attributes from json file
	[Wed, 14 Dec 2011 22:43:04 +0000] DEBUG: Platform is fedora version 15
	[Wed, 14 Dec 2011 22:43:04 +0000] INFO: Run List is [recipe[onebox::broken]]
	[Wed, 14 Dec 2011 22:43:04 +0000] INFO: Run List expands to [onebox::broken]
	[Wed, 14 Dec 2011 22:43:04 +0000] INFO: Starting Chef Run for cionebox
	[Wed, 14 Dec 2011 22:43:04 +0000] INFO: Running start handlers
	[Wed, 14 Dec 2011 22:43:04 +0000] INFO: Start handlers complete.
	[Wed, 14 Dec 2011 22:43:04 +0000] DEBUG: No chefignore file found at /opt/titan/chef/cookbooks/chefignore no files will be ignored
	[Wed, 14 Dec 2011 22:43:05 +0000] DEBUG: Loading cookbook endpoint's library file: /opt/titan/chef/cookbooks/endpoint/libraries/chef_ext.rb
	[Wed, 14 Dec 2011 22:43:05 +0000] DEBUG: Loading cookbook endpoint's library file: /opt/titan/chef/cookbooks/endpoint/libraries/bindings.rb
	[Wed, 14 Dec 2011 22:43:05 +0000] DEBUG: Loading cookbook yggdrasil's providers from /opt/titan/chef/cookbooks/yggdrasil/providers/event.rb
	[Wed, 14 Dec 2011 22:43:05 +0000] DEBUG: Loaded contents of /opt/titan/chef/cookbooks/yggdrasil/providers/event.rb into a provider named yggdrasil_event defined in Chef::Provider::YggdrasilEvent
	[Wed, 14 Dec 2011 22:43:05 +0000] DEBUG: Loading cookbook yggdrasil's resources from /opt/titan/chef/cookbooks/yggdrasil/resources/event.rb
	[Wed, 14 Dec 2011 22:43:05 +0000] DEBUG: Loaded contents of /opt/titan/chef/cookbooks/yggdrasil/resources/event.rb into a resource named yggdrasil_event defined in Chef::Resource::YggdrasilEvent
	[Wed, 14 Dec 2011 22:43:05 +0000] DEBUG: Node cionebox loading cookbook graphite's attribute file /opt/titan/chef/cookbooks/graphite/attributes/graphite.rb
	[Wed, 14 Dec 2011 22:43:05 +0000] DEBUG: Loading cookbook munin's definitions from /opt/titan/chef/cookbooks/munin/definitions/munin_plugin.rb
	[Wed, 14 Dec 2011 22:43:05 +0000] DEBUG: Loading Recipe onebox::broken via include_recipe
	[Wed, 14 Dec 2011 22:43:05 +0000] DEBUG: Found recipe broken in cookbook onebox
	[Wed, 14 Dec 2011 22:43:05 +0000] DEBUG: Setting execute[touch_file] to the state of the prior execute[touch_file]
	[Wed, 14 Dec 2011 22:43:05 +0000] DEBUG: Loading from cookbook_path: /opt/titan/chef/cookbooks
	[Wed, 14 Dec 2011 22:43:05 +0000] DEBUG: Converging node cionebox
	[Wed, 14 Dec 2011 22:43:05 +0000] DEBUG: Processing execute[touch_file] on cionebox
	[Wed, 14 Dec 2011 22:43:05 +0000] INFO: Processing execute[touch_file] action run (onebox::broken line 3)
	[Wed, 14 Dec 2011 22:43:05 +0000] DEBUG: sh(ls /tmp/one.txt)
	[Wed, 14 Dec 2011 22:43:05 +0000] DEBUG: sh(ls /tmp/two.txt)
	[Wed, 14 Dec 2011 22:43:05 +0000] INFO: execute[touch_file] sh(touch /tmp/one.txt)
	[Wed, 14 Dec 2011 22:43:05 +0000] INFO: execute[touch_file] ran successfully
	[Wed, 14 Dec 2011 22:43:05 +0000] DEBUG: Processing execute[touch_file] on cionebox
	[Wed, 14 Dec 2011 22:43:05 +0000] INFO: Processing execute[touch_file] action run (onebox::broken line 3)
	[Wed, 14 Dec 2011 22:43:05 +0000] DEBUG: sh(ls /tmp/one.txt)
	/tmp/one.txt
	[Wed, 14 Dec 2011 22:43:05 +0000] DEBUG: Skipping execute[touch_file] due to not_if command `ls /tmp/one.txt`
	[Wed, 14 Dec 2011 22:43:05 +0000] DEBUG: Processing execute[ls_file] on cionebox
	[Wed, 14 Dec 2011 22:43:05 +0000] INFO: Processing execute[ls_file] action run (onebox::broken line 9)
	[Wed, 14 Dec 2011 22:43:05 +0000] INFO: execute[ls_file] sh(ls /tmp/two.txt)
	[Wed, 14 Dec 2011 22:43:05 +0000] ERROR: execute[ls_file] (onebox::broken line 9) has had an error
	[Wed, 14 Dec 2011 22:43:05 +0000] ERROR: execute[ls_file] (/opt/titan/chef/cookbooks/onebox/recipes/broken.rb:9:in `from_file') had an error:
	execute[ls_file] (onebox::broken line 9) had an error: Chef::Exceptions::ShellCommandFailed: Expected process to exit with [0], but received '2'
	---- Begin output of ls /tmp/two.txt ----
	STDOUT: 
	STDERR: ls: cannot access /tmp/two.txt: No such file or directory
	---- End output of ls /tmp/two.txt ----
	Ran ls /tmp/two.txt returned 2
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/shell_out.rb:206:in `invalid!'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/shell_out.rb:192:in `error!'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/mixin/shell_out.rb:36:in `shell_out!'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/provider/execute.rb:58:in `action_run'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/resource.rb:440:in `send'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/resource.rb:440:in `run_action'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/runner.rb:45:in `run_action'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/runner.rb:81:in `converge'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/runner.rb:81:in `each'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/runner.rb:81:in `converge'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/resource_collection.rb:94:in `execute_each_resource'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/resource_collection/stepable_iterator.rb:116:in `call'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/resource_collection/stepable_iterator.rb:116:in `call_iterator_block'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/resource_collection/stepable_iterator.rb:85:in `step'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/resource_collection/stepable_iterator.rb:104:in `iterate'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/resource_collection/stepable_iterator.rb:55:in `each_with_index'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/resource_collection.rb:92:in `execute_each_resource'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/runner.rb:76:in `converge'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/client.rb:312:in `converge'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/client.rb:160:in `run'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/application/solo.rb:192:in `run_application'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/application/solo.rb:183:in `loop'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/application/solo.rb:183:in `run_application'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/application.rb:67:in `run'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/chef-solo:25
	/usr/bin/chef-solo:19:in `load'
	/usr/bin/chef-solo:19
	[Wed, 14 Dec 2011 22:43:05 +0000] ERROR: Running exception handlers
	[Wed, 14 Dec 2011 22:43:05 +0000] INFO: Resources updated this run:
	[Wed, 14 Dec 2011 22:43:05 +0000] INFO:   execute[touch_file]
	[Wed, 14 Dec 2011 22:43:05 +0000] ERROR: Exception handlers complete
	[Wed, 14 Dec 2011 22:43:05 +0000] DEBUG: Re-raising exception: Chef::Exceptions::ShellCommandFailed - execute[ls_file] (onebox::broken line 9) had an error: Chef::Exceptions::ShellCommandFailed: Expected process to exit with [0], but received '2'
	---- Begin output of ls /tmp/two.txt ----
	STDOUT: 
	STDERR: ls: cannot access /tmp/two.txt: No such file or directory
	---- End output of ls /tmp/two.txt ----
	Ran ls /tmp/two.txt returned 2
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/shell_out.rb:206:in `invalid!'
	  /usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/shell_out.rb:192:in `error!'
	  /usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/mixin/shell_out.rb:36:in `shell_out!'
	  /usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/provider/execute.rb:58:in `action_run'
	  /usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/resource.rb:440:in `send'
	  /usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/resource.rb:440:in `run_action'
	  /usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/runner.rb:45:in `run_action'
	  /usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/runner.rb:81:in `converge'
	  /usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/runner.rb:81:in `each'
	  /usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/runner.rb:81:in `converge'
	  /usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/resource_collection.rb:94:in `execute_each_resource'
	  /usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/resource_collection/stepable_iterator.rb:116:in `call'
	  /usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/resource_collection/stepable_iterator.rb:116:in `call_iterator_block'
	  /usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/resource_collection/stepable_iterator.rb:85:in `step'
	  /usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/resource_collection/stepable_iterator.rb:104:in `iterate'
	  /usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/resource_collection/stepable_iterator.rb:55:in `each_with_index'
	  /usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/resource_collection.rb:92:in `execute_each_resource'
	  /usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/runner.rb:76:in `converge'
	  /usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/client.rb:312:in `converge'
	  /usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/client.rb:160:in `run'
	  /usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/application/solo.rb:192:in `run_application'
	  /usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/application/solo.rb:183:in `loop'
	  /usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/application/solo.rb:183:in `run_application'
	  /usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/application.rb:67:in `run'
	  /usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/chef-solo:25
	  /usr/bin/chef-solo:19:in `load'
	  /usr/bin/chef-solo:19
	[Wed, 14 Dec 2011 22:43:05 +0000] FATAL: Stacktrace dumped to /var/chef/cache/chef-stacktrace.out
	[Wed, 14 Dec 2011 22:43:05 +0000] DEBUG: Chef::Exceptions::ShellCommandFailed: execute[ls_file] (onebox::broken line 9) had an error: Chef::Exceptions::ShellCommandFailed: Expected process to exit with [0], but received '2'
	---- Begin output of ls /tmp/two.txt ----
	STDOUT: 
	STDERR: ls: cannot access /tmp/two.txt: No such file or directory
	---- End output of ls /tmp/two.txt ----
	Ran ls /tmp/two.txt returned 2
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/shell_out.rb:206:in `invalid!'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/shell_out.rb:192:in `error!'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/mixin/shell_out.rb:36:in `shell_out!'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/provider/execute.rb:58:in `action_run'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/resource.rb:440:in `send'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/resource.rb:440:in `run_action'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/runner.rb:45:in `run_action'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/runner.rb:81:in `converge'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/runner.rb:81:in `each'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/runner.rb:81:in `converge'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/resource_collection.rb:94:in `execute_each_resource'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/resource_collection/stepable_iterator.rb:116:in `call'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/resource_collection/stepable_iterator.rb:116:in `call_iterator_block'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/resource_collection/stepable_iterator.rb:85:in `step'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/resource_collection/stepable_iterator.rb:104:in `iterate'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/resource_collection/stepable_iterator.rb:55:in `each_with_index'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/resource_collection.rb:92:in `execute_each_resource'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/runner.rb:76:in `converge'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/client.rb:312:in `converge'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/client.rb:160:in `run'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/application/solo.rb:192:in `run_application'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/application/solo.rb:183:in `loop'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/application/solo.rb:183:in `run_application'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/../lib/chef/application.rb:67:in `run'
	/usr/lib/ruby/gems/1.8/gems/chef-0.10.6/bin/chef-solo:25
	/usr/bin/chef-solo:19:in `load'
	/usr/bin/chef-solo:19
	[Wed, 14 Dec 2011 22:43:05 +0000] FATAL: Chef::Exceptions::ShellCommandFailed: execute[ls_file] (onebox::broken line 9) had an error: Chef::Exceptions::ShellCommandFailed: Expected process to exit with [0], but received '2'
	---- Begin output of ls /tmp/two.txt ----
	STDOUT: 
	STDERR: ls: cannot access /tmp/two.txt: No such file or directory
	---- End output of ls /tmp/two.txt ----
	Ran ls /tmp/two.txt returned 2

Issue Links

is duplicated by

Bug - A problem which impairs or prevents the functions of the product. CHEF-894 chef resources inherit not_if and only_if from previous copies

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. CHEF-2666 don't inherit "source" attribute on templates

  • Unknown - Issue untriaged, priority unassigned or questioned
  • Closed - The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. CHEF-2892 Second call to a definition fails because of the state of first call.

  • Unknown - Issue untriaged, priority unassigned or questioned
  • Closed - The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.
relates to

New Feature - A new feature of the product, which has yet to be developed. CHEF-26 When you have a resource with the same name, it should inherit the pre-existing resources attributes

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. CHEF-3694 Resource cloning should be removed

  • Unknown - Issue untriaged, priority unassigned or questioned
  • Open - The issue is open and ready for the assignee to start work on it.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Geoff Papilion added a comment -

I'm seeing similar behavior in 10.8, which broke one of our cookbooks.

we're going to work around this in the shell script the recipe runs.

Show
Geoff Papilion added a comment - I'm seeing similar behavior in 10.8, which broke one of our cookbooks. we're going to work around this in the shell script the recipe runs.
Hide
Permalink
Geoff Papilion added a comment - - edited

Also there is a workaround to the issue:

files = %w(one.txt two.txt)
files.each do |filename|
  execute "touch_file_#{filename}" do
    command "touch /tmp/#{filename}"

    # It works without this 'not_if'
    not_if "ls /tmp/#{filename}"
  end
end

I'm looking to see where I can patch this behavior.

Show
Geoff Papilion added a comment - - edited Also there is a workaround to the issue: files = %w(one.txt two.txt) files.each do |filename| execute "touch_file_#{filename}" do command "touch /tmp/#{filename}" # It works without this 'not_if' not_if "ls /tmp/#{filename}" end end I'm looking to see where I can patch this behavior.
Hide
Permalink
Geoff Papilion added a comment -

I put a oneline fix into a chef branch I have on github.... basically i ignore only_if, and not_if instance variables when loading from prior resources.

https://github.com/gpapilion/chef/blob/master/chef/lib/chef/resource.rb#L157

Show
Geoff Papilion added a comment - I put a oneline fix into a chef branch I have on github.... basically i ignore only_if, and not_if instance variables when loading from prior resources. https://github.com/gpapilion/chef/blob/master/chef/lib/chef/resource.rb#L157
Hide
Permalink
Daniel DeLeo added a comment -

I'm not convinced this is a bug. You just need to give your resources different names:

%w[one two].each do |name|
  execute "touch_file_#{name}" do
  # more stuff here
  end
end

I can definitely buy that the argument that resource names have to be unique and new resources get edited is (a) poorly documented and (b) unexpected/confusing; I'm certainly open to ideas or discussion about how to improve it. As it stands now, this is the intended behavior, and is used to do things such as add new values to the variables parameter of a template resource.

Show
Daniel DeLeo added a comment - I'm not convinced this is a bug. You just need to give your resources different names: %w[one two].each do |name| execute "touch_file_#{name}" do # more stuff here end end I can definitely buy that the argument that resource names have to be unique and new resources get edited is (a) poorly documented and (b) unexpected/confusing; I'm certainly open to ideas or discussion about how to improve it. As it stands now, this is the intended behavior, and is used to do things such as add new values to the variables parameter of a template resource.
Hide
Permalink
Geoff Papilion added a comment -

I've run this through shef, and this is what I found:

chef:recipe > run_context.resource_collection[0].inspect
 => "<execute[touch_file] @cookbook_name: nil @retries: 0 @updated: false @allowed_actions: [:nothing, :run] @name: \"touch_file\" @creates: nil @resource_name: :execute @delayed_notifications: [] @before: nil @ignore_failure: false @user: nil @timeout: nil @action: \"run\" @enclosing_provider: nil @immediate_notifications: [] @noop: nil @supports: {} @group: nil @cwd: nil @backup: 5 @command: \"touch /tmp/one.txt\" @source_line: \"(irb#1):4:in `irb_binding'\" @provider: nil @recipe_name: nil @retry_delay: 2 @umask: nil @updated_by_last_action: false @returns: 0 @path: nil @environment: nil @params: {}>" 

chef:recipe > run_context.resource_collection[0].not_if.inspect
 => "[#<Chef::Resource::Conditional:0x7f9440b04740 @block=nil, @command_opts={}, @command=\"ls /tmp/one.txt\", @positivity=:not_if>, #<Chef::Resource::Conditional:0x7f9440b038b8 @block=nil, @command_opts={}, @command=\"ls /tmp/two.txt\", @positivity=:not_if>]"

chef:recipe > run_context.resource_collection[1].inspect
 => "<execute[touch_file] @cookbook_name: nil @retries: 0 @updated: false @allowed_actions: [:nothing, :run] @name: \"touch_file\" @creates: nil @resource_name: :execute @delayed_notifications: [] @before: nil @ignore_failure: false @user: nil @timeout: nil @action: \"run\" @enclosing_provider: nil @immediate_notifications: [] @noop: nil @supports: {} @group: nil @cwd: nil @backup: 5 @command: \"touch /tmp/two.txt\" @source_line: \"(irb#1):4:in `irb_binding'\" @provider: nil @recipe_name: nil @retry_delay: 2 @umask: nil @updated_by_last_action: false @returns: 0 @path: nil @environment: nil @params: {}>" 

chef:recipe > run_context.resource_collection[1].not_if.inspect
 => "[#<Chef::Resource::Conditional:0x7f9440b04740 @block=nil, @command_opts={}, @command=\"ls /tmp/one.txt\", @positivity=:not_if>, #<Chef::Resource::Conditional:0x7f9440b038b8 @block=nil, @command_opts={}, @command=\"ls /tmp/two.txt\", @positivity=:not_if>]" 

resource_collection[0].not_if is the same array reference as resource_collection[1].not_if.

I'm not sure this is intentional, so I've patched the load_prior method to ignore not_if and only_if conditions.

Show
Geoff Papilion added a comment - I've run this through shef, and this is what I found: chef:recipe > run_context.resource_collection[0].inspect => "<execute[touch_file] @cookbook_name: nil @retries: 0 @updated: false @allowed_actions: [:nothing, :run] @name: \" touch_file\ " @creates: nil @resource_name: :execute @delayed_notifications: [] @before: nil @ignore_failure: false @user: nil @timeout: nil @action: \" run\ " @enclosing_provider: nil @immediate_notifications: [] @noop: nil @supports: {} @group: nil @cwd: nil @backup: 5 @command: \" touch /tmp/one.txt\ " @source_line: \" (irb#1):4:in `irb_binding'\ " @provider: nil @recipe_name: nil @retry_delay: 2 @umask: nil @updated_by_last_action: false @returns: 0 @path: nil @environment: nil @params: {}>" chef:recipe > run_context.resource_collection[0].not_if.inspect => "[#<Chef::Resource::Conditional:0x7f9440b04740 @block=nil, @command_opts={}, @command=\" ls /tmp/one.txt\ ", @positivity=:not_if>, #<Chef::Resource::Conditional:0x7f9440b038b8 @block=nil, @command_opts={}, @command=\" ls /tmp/two.txt\ ", @positivity=:not_if>]" chef:recipe > run_context.resource_collection[1].inspect => "<execute[touch_file] @cookbook_name: nil @retries: 0 @updated: false @allowed_actions: [:nothing, :run] @name: \" touch_file\ " @creates: nil @resource_name: :execute @delayed_notifications: [] @before: nil @ignore_failure: false @user: nil @timeout: nil @action: \" run\ " @enclosing_provider: nil @immediate_notifications: [] @noop: nil @supports: {} @group: nil @cwd: nil @backup: 5 @command: \" touch /tmp/two.txt\ " @source_line: \" (irb#1):4:in `irb_binding'\ " @provider: nil @recipe_name: nil @retry_delay: 2 @umask: nil @updated_by_last_action: false @returns: 0 @path: nil @environment: nil @params: {}>" chef:recipe > run_context.resource_collection[1].not_if.inspect => "[#<Chef::Resource::Conditional:0x7f9440b04740 @block=nil, @command_opts={}, @command=\" ls /tmp/one.txt\ ", @positivity=:not_if>, #<Chef::Resource::Conditional:0x7f9440b038b8 @block=nil, @command_opts={}, @command=\" ls /tmp/two.txt\ ", @positivity=:not_if>]" resource_collection[0].not_if is the same array reference as resource_collection[1].not_if. I'm not sure this is intentional, so I've patched the load_prior method to ignore not_if and only_if conditions.
Hide
Permalink
Nick Stielau added a comment -

I think this is the expected and desired behavior (although it is different from previous versions). I think it should be kept the way it is, and not made backwards compatible. If anything, I think the 'Setting execute[touch_file] to the state of the prior execute[touch_file]' log entry could be a WARN, and could indicate potentially undesired consequences.

Show
Nick Stielau added a comment - I think this is the expected and desired behavior (although it is different from previous versions). I think it should be kept the way it is, and not made backwards compatible. If anything, I think the 'Setting execute [touch_file] to the state of the prior execute [touch_file] ' log entry could be a WARN, and could indicate potentially undesired consequences.
Hide
Permalink
Justin Alan Ryan added a comment -

I don't have a strong opinion either way as to whether this behaviour is appropriate, but better documentation and esp. error message would go a long way.

From a software design perspective, that it works this way makes sense, but when a problem creeps up related to it, it's unintuitive that this is happening.

Show
Justin Alan Ryan added a comment - I don't have a strong opinion either way as to whether this behaviour is appropriate, but better documentation and esp. error message would go a long way. From a software design perspective, that it works this way makes sense, but when a problem creeps up related to it, it's unintuitive that this is happening.
Hide
Permalink
Geoff Papilion added a comment -

If I create several execute object identified by "foo" then "foo" should either be immutable, ora new object. Right now it behaves as if some attributes can be changed, but not all. The current documentation/behavior implies that "foo" is not a unique identifier. In fact, "foo" 1 and "foo"2 share no attributes, save array objects which are duplicated since ruby is storing the reference to the array in the object and not the array values.

I think it should be one way or the other, but if its that foo is a unique identifier it should throw an unrecoverable error for the user to deal with.

Show
Geoff Papilion added a comment - If I create several execute object identified by "foo" then "foo" should either be immutable, ora new object. Right now it behaves as if some attributes can be changed, but not all. The current documentation/behavior implies that "foo" is not a unique identifier. In fact, "foo" 1 and "foo"2 share no attributes, save array objects which are duplicated since ruby is storing the reference to the array in the object and not the array values. I think it should be one way or the other, but if its that foo is a unique identifier it should throw an unrecoverable error for the user to deal with.
Hide
Permalink
Bryan McLellan [Opscode] added a comment -

Chef resources are unique by type and name. These objects are not immutable and remain a single object of which attributes CAN be changes. 

### btm-daemon/recipes/default.rb
file "btm-daemon_file" do
   path "/tmp/log_file"
   owner "btm"
   group "btm"
   mode "0600"
   content "one" # normally we irrelevant, but included for the example.
   action :nothing
end

### thing_that_wants_btm-daemon/recipes/default.rb

include_recipe "btm-daemon"

# generate some stuff into 'output_of_stuff'
output_of_stuff = "two"

file "btm-daemon_file" do
  content output_of_stuff
  action :create
end

# /tmp/log_file now contains "two"

This allows you to use a resource in multiple recipes and cookbooks without have to redefine all of its attributes, thus allowing them to be configured in a single location.

For historical context, the next example is COOK-58 and CHEF-26. This functionality has been leveraged in the past in the apache cookbook to avoid starting apache until all of the configuration files are written, allowing Chef to fix a configuration file which would prevent apache to start, thus breaking the chef run, requiring manual intervention.

service "apache2" do
  case node[:platform]
  when "redhat","centos","scientific","fedora","suse"
    service_name "httpd"
    # If restarted/reloaded too quickly httpd has a habit of failing.
    # This may happen with multiple recipes notifying apache to restart - like
    # during the initial bootstrap.
    restart_command "/sbin/service httpd restart && sleep 1"
    reload_command "/sbin/service httpd reload && sleep 1"
  when "debian","ubuntu"
    service_name "apache2"
    restart_command "/usr/sbin/invoke-rc.d apache2 restart && sleep 1"
    reload_command "/usr/sbin/invoke-rc.d apache2 reload && sleep 1"
  when "arch"
    service_name "httpd"
  when "freebsd"
    service_name "apache22"
  end
  supports value_for_platform(
    "debian" => { "4.0" => [ :restart, :reload ], "default" => [ :restart, :reload, :status ] },
    "ubuntu" => { "default" => [ :restart, :reload, :status ] },
    "redhat" => { "default" => [ :restart, :reload, :status ] },
    "centos" => { "default" => [ :restart, :reload, :status ] },
    "scientific" => { "default" => [ :restart, :reload, :status ] },
    "fedora" => { "default" => [ :restart, :reload, :status ] },
    "arch" => { "default" => [ :restart, :reload, :status ] },
    "suse" => { "default" => [ :restart, :reload, :status ] },
    "freebsd" => { "default" => [ :restart, :reload, :status ] },
    "default" => { "default" => [:restart, :reload ] }
  )
  action :enable
end

# lots of templates

service "apache2" do
  action :start
end

At the time, prior to CHEF-899, you could not notify a service that hadn't been previously defined in the recipe because during the compile phase we tried to resolve the resource you wanted to notify but it did not yet exist. CHEF-899 moved that to the beginning of the convergence phase.

What I think is most confusing here is that you cannot override the not_if attribute like you can the others.

file "/tmp/always_here"

file "my_file" do
   path "/tmp/log_file"
   owner "btm"
   group "btm"
   mode "0600"
   content "one"
   action :nothing
   not_if { File.exists? "/tmp/always_here" } # This prevents an action, not the resource creation
end

file "my_file" do
  content "two"
  action :create
  not_if { File.exists? "/tmp/log_file" } # This fails to override the earlier not_if, and no action is made.
end

Before run:

btm@btm-mbp-dev:/tmp $ ls log_file always_here 
ls: cannot access log_file: No such file or directory
ls: cannot access always_here: No such file or directory

After run:

btm@btm-mbp-dev:/tmp $ ls log_file always_here 
ls: cannot access log_file: No such file or directory
always_here
Show
Bryan McLellan [Opscode] added a comment - Chef resources are unique by type and name. These objects are not immutable and remain a single object of which attributes CAN be changes. ### btm-daemon/recipes/ default .rb file "btm-daemon_file" do path "/tmp/log_file" owner "btm" group "btm" mode "0600" content "one" # normally we irrelevant, but included for the example. action :nothing end ### thing_that_wants_btm-daemon/recipes/ default .rb include_recipe "btm-daemon" # generate some stuff into 'output_of_stuff' output_of_stuff = "two" file "btm-daemon_file" do content output_of_stuff action :create end # /tmp/log_file now contains "two" This allows you to use a resource in multiple recipes and cookbooks without have to redefine all of its attributes, thus allowing them to be configured in a single location. For historical context, the next example is COOK-58 and CHEF-26 . This functionality has been leveraged in the past in the apache cookbook to avoid starting apache until all of the configuration files are written, allowing Chef to fix a configuration file which would prevent apache to start, thus breaking the chef run, requiring manual intervention. service "apache2" do case node[:platform] when "redhat" , "centos" , "scientific" , "fedora" , "suse" service_name "httpd" # If restarted/reloaded too quickly httpd has a habit of failing. # This may happen with multiple recipes notifying apache to restart - like # during the initial bootstrap. restart_command "/sbin/service httpd restart && sleep 1" reload_command "/sbin/service httpd reload && sleep 1" when "debian" , "ubuntu" service_name "apache2" restart_command "/usr/sbin/invoke-rc.d apache2 restart && sleep 1" reload_command "/usr/sbin/invoke-rc.d apache2 reload && sleep 1" when "arch" service_name "httpd" when "freebsd" service_name "apache22" end supports value_for_platform( "debian" => { "4.0" => [ :restart, :reload ], " default " => [ :restart, :reload, :status ] }, "ubuntu" => { " default " => [ :restart, :reload, :status ] }, "redhat" => { " default " => [ :restart, :reload, :status ] }, "centos" => { " default " => [ :restart, :reload, :status ] }, "scientific" => { " default " => [ :restart, :reload, :status ] }, "fedora" => { " default " => [ :restart, :reload, :status ] }, "arch" => { " default " => [ :restart, :reload, :status ] }, "suse" => { " default " => [ :restart, :reload, :status ] }, "freebsd" => { " default " => [ :restart, :reload, :status ] }, " default " => { " default " => [:restart, :reload ] } ) action :enable end # lots of templates service "apache2" do action :start end At the time, prior to CHEF-899 , you could not notify a service that hadn't been previously defined in the recipe because during the compile phase we tried to resolve the resource you wanted to notify but it did not yet exist. CHEF-899 moved that to the beginning of the convergence phase. What I think is most confusing here is that you cannot override the not_if attribute like you can the others. file "/tmp/always_here" file "my_file" do path "/tmp/log_file" owner "btm" group "btm" mode "0600" content "one" action :nothing not_if { File.exists? "/tmp/always_here" } # This prevents an action, not the resource creation end file "my_file" do content "two" action :create not_if { File.exists? "/tmp/log_file" } # This fails to override the earlier not_if, and no action is made. end Before run: btm@btm-mbp-dev:/tmp $ ls log_file always_here ls: cannot access log_file: No such file or directory ls: cannot access always_here: No such file or directory After run: btm@btm-mbp-dev:/tmp $ ls log_file always_here ls: cannot access log_file: No such file or directory always_here
Hide
Permalink
Geoff Papilion added a comment -

Makes sense.

So, is the not_if/only_if issue by design or by accident?

I put a patch that excludes the conditionals from the attribute copy, but if this is by design this makes no sense.

If its by design, I'm happy with close won't fix.

Show
Geoff Papilion added a comment - Makes sense. So, is the not_if/only_if issue by design or by accident? I put a patch that excludes the conditionals from the attribute copy, but if this is by design this makes no sense. If its by design, I'm happy with close won't fix.
Hide
Permalink
Bryan McLellan [Opscode] added a comment -

One side-effect of the functionality that I outlined in my last comment is that we internally create two resources, where the second one copies the first.

https://github.com/opscode/chef/blob/master/chef/lib/chef/mixin/recipe_definition_dsl_core.rb#L66

# If we have a resource like this one, we want to steal its state
          args << run_context
          resource = resource_class.new(*args)
          resource.load_prior_resource
          resource.cookbook_name = cookbook_name
          resource.recipe_name = @recipe_name
          resource.params = @params
          resource.source_line = caller[0]

Consequently, other actions like notifies will have more than one resource of the same name and type to choose from, in a non-obvious manner.

Show
Bryan McLellan [Opscode] added a comment - One side-effect of the functionality that I outlined in my last comment is that we internally create two resources, where the second one copies the first. https://github.com/opscode/chef/blob/master/chef/lib/chef/mixin/recipe_definition_dsl_core.rb#L66 # If we have a resource like this one, we want to steal its state args << run_context resource = resource_class. new (*args) resource.load_prior_resource resource.cookbook_name = cookbook_name resource.recipe_name = @recipe_name resource.params = @params resource.source_line = caller[0] Consequently, other actions like notifies will have more than one resource of the same name and type to choose from, in a non-obvious manner.
Hide
Permalink
Bryan McLellan [Opscode] added a comment -

Need to research how CHEF-894 relates to this.

Show
Bryan McLellan [Opscode] added a comment - Need to research how CHEF-894 relates to this.
Hide
Permalink
Bryan McLellan [Opscode] added a comment -

Patch with no CLA.

https://github.com/opscode/chef/pull/214

Show
Bryan McLellan [Opscode] added a comment - Patch with no CLA. https://github.com/opscode/chef/pull/214
Hide
Permalink
Geoff Papilion added a comment -

I'm on my companies CLA, Wikia Inc. I have a series of emails with Jennifer confirming this in January.

Show
Geoff Papilion added a comment - I'm on my companies CLA, Wikia Inc. I have a series of emails with Jennifer confirming this in January.
Hide
Permalink
Geoff Papilion added a comment -

I should have a CCLA on file w/ wikia-inc

Show
Geoff Papilion added a comment - I should have a CCLA on file w/ wikia-inc
Hide
Permalink
Bryan McLellan [Opscode] added a comment -

Thanks Geoff, I probably stumbled on the pull requrest and searched for your name on the Github account on the Approved Contributors list and did not find it. I've asked Jamie to fix that up.

Because you're in the jira-developers group on JIRA (which means you have a CLA) you can follow the contribution work flow and mark a ticket 'Fix Provided' when you've got a patch ready for review.

http://wiki.opscode.com/display/chef/Code+Review

Show
Bryan McLellan [Opscode] added a comment - Thanks Geoff, I probably stumbled on the pull requrest and searched for your name on the Github account on the Approved Contributors list and did not find it. I've asked Jamie to fix that up. Because you're in the jira-developers group on JIRA (which means you have a CLA) you can follow the contribution work flow and mark a ticket 'Fix Provided' when you've got a patch ready for review. http://wiki.opscode.com/display/chef/Code+Review
Hide
Permalink
Bryan McLellan [Opscode] added a comment -

https://github.com/gpapilion/chef/commit/2ef615bc54d38d2c82c79a7af4419dec7f51e11d

Show
Bryan McLellan [Opscode] added a comment - https://github.com/gpapilion/chef/commit/2ef615bc54d38d2c82c79a7af4419dec7f51e11d
Hide
Permalink
Bryan McLellan [Opscode] added a comment -

This should work.

We should output a warning when we're duplicating a resource, include the file and line number where this is happening, and say that we want to remove this. Maybe point to this ticket somewhere.

If we had a top-level notification resource, we could probably start pulling down this feature, now that notifications are so strong.

Show
Bryan McLellan [Opscode] added a comment - This should work. We should output a warning when we're duplicating a resource, include the file and line number where this is happening, and say that we want to remove this. Maybe point to this ticket somewhere. If we had a top-level notification resource, we could probably start pulling down this feature, now that notifications are so strong.
Hide
Permalink
Bryan McLellan [Opscode] added a comment -

https://github.com/opscode/chef/pull/540

Show
Bryan McLellan [Opscode] added a comment - https://github.com/opscode/chef/pull/540

People

  • Assignee:
    Bryan McLellan [Opscode]
    Reporter:
    Nick Stielau
Vote (2)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: