Chef

Git resource setting updated too often, causing notifications to trigger inappropriately

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Fixed
  • Affects Version/s: 0.7.14
  • Fix Version/s: 0.9.10
  • Component/s: Chef Client
  • Labels:
    None
  • Environment:

    SLES11 client/server

  • Triage Status:
    Triaged

Description

i have recipe:

git "#{node[:nsd][:config_dir]}/etc/zones/master" do
repository "...."
reference "HEAD"
notifies :reload, resources(:service => "nsd"), :delayed
action :sync
end

template "#{node[:nsd][:config_dir]}/etc/nsd.conf" do
source "nsd.conf.erb"
variables(:nsd_role => "master")
owner "root"
group "nsd"
mode 0640
notifies :reload, resources(:service => "nsd"), :delayed
end

On client i have such logfile:

[Wed, 02 Dec 2009 18:39:47 +0300] DEBUG: Cached template for template[/var/lib/nsd/etc/nsd.conf] is unchanged
[Wed, 02 Dec 2009 18:39:47 +0300] DEBUG: template[/var/lib/nsd/etc/nsd.conf] is unchanged
[Wed, 02 Dec 2009 18:39:47 +0300] INFO: git[/var/lib/nsd/etc/zones/master] sending reload action to service[nsd]

Why chef reloading nsd on each run when source files are unchanged?

Activity

Hide
Adam Jacob added a comment - 20/Jul/10 6:51 AM

The issue here is that the git resource is setting @new_resource.updated way too often - for example, it's always set when sync is run, no matter if there were changes.

Show
Adam Jacob added a comment - 20/Jul/10 6:51 AM The issue here is that the git resource is setting @new_resource.updated way too often - for example, it's always set when sync is run, no matter if there were changes.
Hide
Toomas Pelberg added a comment - 11/Aug/10 5:54 AM

Please merge with http://github.com/toomasp/chef/tree/CHEF-767

$ spec -bcfs chef/spec/unit/provider/git_spec.rb 

Chef::Provider::Git
- creates a current_resource with the currently deployed revision when a clone exists in the destination dir
- keeps the node and resource passed to it on initialize
- responds to :revision_slug as an alias for revision_sha
- runs a clone command with default git options
- compiles a clone command using --depth for shallow cloning
- compiles a clone command with a remote other than ``origin''
- runs a checkout command with default options
- runs an enable_submodule command
- does nothing for enable_submodules if resource.enable_submodules #=> false
- runs a sync command with default options
- runs a sync command with the user and group specified in the resource
- compiles a sync command using remote tracking branches when remote is not ``origin''
- does a checkout running the clone command then running the after clone command from the destination dir
- should not checkout if the destination exists or is a non empty directory
- does a sync by running the sync command
- does a sync and gets a new version
- does a checkout instead of sync if the deploy directory doesn't exist
- does a checkout instead of sync if the deploy directory is empty
- does an export by cloning the repo then removing the .git directory

Chef::Provider::Git determining the revision of the currently deployed checkout
- sets the current revison to nil if the deploy dir does not exist
- determines the current revision when there is one
- gives the current revision as nil when there is no current revision

Chef::Provider::Git resolving revisions to a SHA
- returns resource.revision as is if revision is already a full SHA
- converts resource.revision from a tag to a SHA
- raises a runtime error if you try to deploy from ``origin''
- raises a runtime error if the revision can't be resolved to any revision
- gives the latest HEAD revision SHA if nothing is specified

Finished in 0.051011 seconds

27 examples, 0 failures
Show
Toomas Pelberg added a comment - 11/Aug/10 5:54 AM Please merge with http://github.com/toomasp/chef/tree/CHEF-767
$ spec -bcfs chef/spec/unit/provider/git_spec.rb 

Chef::Provider::Git
- creates a current_resource with the currently deployed revision when a clone exists in the destination dir
- keeps the node and resource passed to it on initialize
- responds to :revision_slug as an alias for revision_sha
- runs a clone command with default git options
- compiles a clone command using --depth for shallow cloning
- compiles a clone command with a remote other than ``origin''
- runs a checkout command with default options
- runs an enable_submodule command
- does nothing for enable_submodules if resource.enable_submodules #=> false
- runs a sync command with default options
- runs a sync command with the user and group specified in the resource
- compiles a sync command using remote tracking branches when remote is not ``origin''
- does a checkout running the clone command then running the after clone command from the destination dir
- should not checkout if the destination exists or is a non empty directory
- does a sync by running the sync command
- does a sync and gets a new version
- does a checkout instead of sync if the deploy directory doesn't exist
- does a checkout instead of sync if the deploy directory is empty
- does an export by cloning the repo then removing the .git directory

Chef::Provider::Git determining the revision of the currently deployed checkout
- sets the current revison to nil if the deploy dir does not exist
- determines the current revision when there is one
- gives the current revision as nil when there is no current revision

Chef::Provider::Git resolving revisions to a SHA
- returns resource.revision as is if revision is already a full SHA
- converts resource.revision from a tag to a SHA
- raises a runtime error if you try to deploy from ``origin''
- raises a runtime error if the revision can't be resolved to any revision
- gives the latest HEAD revision SHA if nothing is specified

Finished in 0.051011 seconds

27 examples, 0 failures
Hide
Daniel DeLeo added a comment - 23/Aug/10 4:18 PM

Merged to master. Thanks, Toomas! One tiny nitpick (which I fixed): you should test the outcome instead of the implementation whenever possible, i.e., use value.should == expected instead of object.should_receive(:method_call) if you can. That way we can change the implementation without affecting the tests.

Show
Daniel DeLeo added a comment - 23/Aug/10 4:18 PM Merged to master. Thanks, Toomas! One tiny nitpick (which I fixed): you should test the outcome instead of the implementation whenever possible, i.e., use value.should == expected instead of object.should_receive(:method_call) if you can. That way we can change the implementation without affecting the tests.
Hide
Joakim Stai added a comment - 04/Feb/11 1:41 PM

I experience the same bug with the :export action.

Code:

git "/usr/share/drush" do
  repository "git://git.drupal.org/project/drush.git"
  revision "7.x-4.2"
  action :export
  notifies :run, "execute[drush update]"
end

# Execute Drush to download dependencies.
execute "drush update" do
  command "drush"
  action :nothing
end

Log:

[Fri, 04 Feb 2011 14:32:15 +0100] INFO: Taking no action, checkout destination /usr/share/drush already exists or is a non-empty directory
[Fri, 04 Feb 2011 14:32:15 +0100] INFO: git[/usr/share/drush] sending run action to execute[drush update] (delayed)

This is in Chef 9.12.

Show
Joakim Stai added a comment - 04/Feb/11 1:41 PM I experience the same bug with the :export action. Code:
git "/usr/share/drush" do
  repository "git://git.drupal.org/project/drush.git"
  revision "7.x-4.2"
  action :export
  notifies :run, "execute[drush update]"
end

# Execute Drush to download dependencies.
execute "drush update" do
  command "drush"
  action :nothing
end
Log:
[Fri, 04 Feb 2011 14:32:15 +0100] INFO: Taking no action, checkout destination /usr/share/drush already exists or is a non-empty directory
[Fri, 04 Feb 2011 14:32:15 +0100] INFO: git[/usr/share/drush] sending run action to execute[drush update] (delayed)
This is in Chef 9.12.

People

Vote (0)
Watch (1)

Dates

  • Created:
    02/Dec/09 3:51 PM
    Updated:
    04/Feb/11 1:41 PM
    Resolved:
    11/Aug/10 5:54 AM