Deployment triggered when it shouldn't be

I have a recipe that, if a remote file is newer (using head), will retrieve it, untar it, stop apache and start apache. It’s been working great and I use it to deploy a number of different builds. It’s been working great, except for one of the latest builds. With this build, it’s deploying every time chef-client runs even though the file hasn’t changed. Any ideas?

Build:
-rw-r–r-- 1 ubuntu ubuntu 131286986 2012-01-08 22:40 stage01.tgz

Code:
http_request “HEAD http tarball” do
url “http://fileserver.foo.com/deployments/#{build}.tgz"
action :head
message ““
if File.exists?(”/tmp/#{build}.tgz”)
headers “If-Modified-Since” => File.mtime(”/tmp/#{build}.tgz").httpdate
end

notifies :create, resources(:remote_file => “/tmp/#{build}.tgz”)
notifies :run, resources(:execute => [ “un-tar” ])
notifies :stop, resources(:service => [ “apache2” ])
notifies :enable, resources(:service => [ “apache2” ])
notifies :start, resources(:service => [ “apache2” ])

end

Logging:
[Mon, 09 Jan 2012 15:25:24 +0000] INFO: http_request[HEAD http tarball] sending create action to remote_file[/tmp/stage01.tgz] (delayed)
[Mon, 09 Jan 2012 15:25:24 +0000] INFO: Processing remote_file[/tmp/stage01.tgz] action create (myco::default line 33)
[Mon, 09 Jan 2012 15:25:26 +0000] DEBUG: remote_file[/tmp/stage01.tgz] checking for changes
[Mon, 09 Jan 2012 15:25:26 +0000] DEBUG: Sending HTTP Request via GET to fileserver.foo.com:80/deployments/stage01.tgz
[Mon, 09 Jan 2012 15:25:26 +0000] DEBUG: Streaming download from http://fileserver.foo.com/deployments/stage01.tgz to tempfile /tmp/chef-rest20120109-31727-1557is9
[Mon, 09 Jan 2012 15:25:30 +0000] DEBUG: remote_file[/tmp/stage01.tgz] checking for file existence of /tmp/stage01.tgz[Mon, 09 Jan 2012 15:25:30 +0000] DEBUG: remote_file[/tmp/stage01.tgz] file exists at /tmp/stage01.tgz
[Mon, 09 Jan 2012 15:25:33 +0000] DEBUG: remote_file[/tmp/stage01.tgz] target checksum: d681fa32efcf797fa00c1d7d753487c434c5760f555370846a01fb563941e229
[Mon, 09 Jan 2012 15:25:33 +0000] DEBUG: remote_file[/tmp/stage01.tgz] source checksum: d681fa32efcf797fa00c1d7d753487c434c5760f555370846a01fb563941e229[Mon, 09 Jan 2012 15:25:33 +0000] DEBUG: remote_file[/tmp/stage01.tgz] target and source checksums are the same - not updating
[Mon, 09 Jan 2012 15:25:33 +0000] INFO: http_request[HEAD http tarball] sending run action to execute[un-tar] (delayed)
[Mon, 09 Jan 2012 15:25:33 +0000] INFO: Processing execute[un-tar] action run (myco::default line 39)
[Mon, 09 Jan 2012 15:25:33 +0000] INFO: execute[un-tar] sh(tar xfz /tmp/stage01.tgz)
[Mon, 09 Jan 2012 15:25:36 +0000] INFO: execute[un-tar] ran successfully
[Mon, 09 Jan 2012 15:25:36 +0000] INFO: http_request[HEAD http tarball] sending stop action to service[apache2] (delayed)
[Mon, 09 Jan 2012 15:25:36 +0000] INFO: Processing service[apache2] action stop (apache::default line 2)
[Mon, 09 Jan 2012 15:25:36 +0000] DEBUG: service[apache2] supports status, running
[Mon, 09 Jan 2012 15:25:36 +0000] DEBUG: Executing /etc/init.d/apache2 status
[Mon, 09 Jan 2012 15:25:36 +0000] DEBUG: ---- Begin output of /etc/init.d/apache2 status ----
[Mon, 09 Jan 2012 15:25:36 +0000] DEBUG: STDOUT: Apache2 is running (pid 31548).
[Mon, 09 Jan 2012 15:25:36 +0000] DEBUG: STDERR:
[Mon, 09 Jan 2012 15:25:36 +0000] DEBUG: ---- End output of /etc/init.d/apache2 status ----
[Mon, 09 Jan 2012 15:25:36 +0000] DEBUG: Ran /etc/init.d/apache2 status returned 0
[Mon, 09 Jan 2012 15:25:36 +0000] DEBUG: service[apache2] is running
[Mon, 09 Jan 2012 15:25:36 +0000] DEBUG: service[apache2] runlevel 0, action stop, priority 20

On Monday, January 9, 2012 at 8:09 AM, Clif Smith wrote:

I have a recipe that, if a remote file is newer (using head), will retrieve it, untar it, stop apache and start apache. It's been working great and I use it to deploy a number of different builds. It's been working great, except for one of the latest builds. With this build, it's deploying every time chef-client runs even though the file hasn't changed. Any ideas?

Have you tried running a request with curl to see if the server is doing the right thing?

--
Dan DeLeo

On Jan 9, 2012, at 10:33 AM, Daniel DeLeo wrote:

On Monday, January 9, 2012 at 8:09 AM, Clif Smith wrote:

I have a recipe that, if a remote file is newer (using head), will retrieve it, untar it, stop apache and start apache. It's been working great and I use it to deploy a number of different builds. It's been working great, except for one of the latest builds. With this build, it's deploying every time chef-client runs even though the file hasn't changed. Any ideas?

Have you tried running a request with curl to see if the server is doing the right thing?

I hadn't prior but it looks good to me:

curl -I Foo.com

HTTP/1.1 200 OK
Date: Mon, 09 Jan 2012 17:58:04 GMT
Server: Apache/2.2.17 (Ubuntu)
Last-Modified: Sun, 08 Jan 2012 22:40:46 GMT
ETag: "24838-7d347ca-4b60bf90fd63d"
Accept-Ranges: bytes
Content-Length: 131286986
Content-Type: application/x-gzip

On Jan 9, 2012, at 12:01 PM, Clif Smith wrote:

On Jan 9, 2012, at 10:33 AM, Daniel DeLeo wrote:

On Monday, January 9, 2012 at 8:09 AM, Clif Smith wrote:

I have a recipe that, if a remote file is newer (using head), will retrieve it, untar it, stop apache and start apache. It's been working great and I use it to deploy a number of different builds. It's been working great, except for one of the latest builds. With this build, it's deploying every time chef-client runs even though the file hasn't changed. Any ideas?

Have you tried running a request with curl to see if the server is doing the right thing?

I hadn't prior but it looks good to me:

curl -I Foo.com

HTTP/1.1 200 OK
Date: Mon, 09 Jan 2012 17:58:04 GMT
Server: Apache/2.2.17 (Ubuntu)
Last-Modified: Sun, 08 Jan 2012 22:40:46 GMT
ETag: "24838-7d347ca-4b60bf90fd63d"
Accept-Ranges: bytes
Content-Length: 131286986
Content-Type: application/x-gzip

I couldn't determine the cause so I deleted the local temp file (/tmp/stage01.tgz). On the next run chef deployed as it should have and hasn't again on subsequent runs (which is a good thing). If anyone has any ideas why this happened, as I'm told it's happened prior, I'd appreciate it.