Newb Question on Deploy Resource


#1

Sorry if this is a totally dumb question, but I can’t seem to find the answer
out there. I was hoping to try and leverage the deploy resource for a simple
app I’ve got in git. I’ve been through the docs at
http://docs.opscode.com/resource_deploy.html and I have things working for the
most part.

The question I have is about expected behavior. It appears that every single
chef run the resource is taking action (including restarting the app) despite
the fact that no changes are pushed to the github repo. We run Chef client on a
schedule, so I’d hate to have the app “deployed” every time chef runs.

So my question is if this is expected or am I doing something wrong? On the
surface this sure doesn’t feel very idempotent, and given the general push to
ensure resources are idempotent this caught me a little of guard.

Here is the uber basic recipe:
deploy “/my/path” do
repo "git://my_git/my_org/my_app.git"
migrate false
symlink_before_migrate({})
restart_command "service httpd restart"
end

Log Entries:
INFO: Processing deploy[/my/path] action deploy (cookbook::default line 15)
INFO: deploy[/my/path] copied the cached checkout to
/my/path/releases/20130313024211
INFO: deploy[/my/path] made pre-migration symlinks
INFO: deploy[/my/path] purged directories in checkout log, tmp/pids,
public/system
INFO: deploy[/my/path] created directories before symlinking tmp,public,config
INFO: deploy[/my/path] linked shared paths into current release: system =>
public/system, pids => tmp/pids, log => log
INFO: deploy[/my/path] made pre-migration symlinks
INFO: deploy[/my/path] linked release /my/path/releases/20130313024211 into
production at /my/path/current
INFO: deploy[/my/path] updated symlinks
INFO: deploy[/my/path] restarting app
INFO: deploy[/my/path] removing old release /my/path/releases/20130313022329
INFO: deploy[/my/path] deployed to /my/path


#2

Hi David,

When using the timestamp deploy mechanism (putting the releases in a structure like this: /my/path/releases/20130313024211) it prevents Chef from being idempotent.

Try switching to the deploy_revision strategy.

Graham


Graham Christensen

On Tuesday, March 12, 2013 at 10:54 PM, davidpetzel@gmail.com wrote:

Sorry if this is a totally dumb question, but I can’t seem to find the answer
out there. I was hoping to try and leverage the deploy resource for a simple
app I’ve got in git. I’ve been through the docs at
http://docs.opscode.com/resource_deploy.html and I have things working for the
most part.

The question I have is about expected behavior. It appears that every single
chef run the resource is taking action (including restarting the app) despite
the fact that no changes are pushed to the github repo. We run Chef client on a
schedule, so I’d hate to have the app “deployed” every time chef runs.

So my question is if this is expected or am I doing something wrong? On the
surface this sure doesn’t feel very idempotent, and given the general push to
ensure resources are idempotent this caught me a little of guard.

Here is the uber basic recipe:
deploy “/my/path” do
repo "git://my_git/my_org/my_app.git"
migrate false
symlink_before_migrate({})
restart_command "service httpd restart"
end

Log Entries:
INFO: Processing deploy[/my/path] action deploy (cookbook::default line 15)
INFO: deploy[/my/path] copied the cached checkout to
/my/path/releases/20130313024211
INFO: deploy[/my/path] made pre-migration symlinks
INFO: deploy[/my/path] purged directories in checkout log, tmp/pids,
public/system
INFO: deploy[/my/path] created directories before symlinking tmp,public,config
INFO: deploy[/my/path] linked shared paths into current release: system =>
public/system, pids => tmp/pids, log => log
INFO: deploy[/my/path] made pre-migration symlinks
INFO: deploy[/my/path] linked release /my/path/releases/20130313024211 into
production at /my/path/current
INFO: deploy[/my/path] updated symlinks
INFO: deploy[/my/path] restarting app
INFO: deploy[/my/path] removing old release /my/path/releases/20130313022329
INFO: deploy[/my/path] deployed to /my/path


#3

Oops - I meant to include a link to the documentation. Here it is: http://docs.opscode.com/resource_deploy.html#deploy-revision


Graham Christensen

On Tuesday, March 12, 2013 at 11:12 PM, Graham Christensen wrote:

Hi David,

When using the timestamp deploy mechanism (putting the releases in a structure like this: /my/path/releases/20130313024211) it prevents Chef from being idempotent.

Try switching to the deploy_revision strategy.

Graham


Graham Christensen

On Tuesday, March 12, 2013 at 10:54 PM, davidpetzel@gmail.com (mailto:davidpetzel@gmail.com) wrote:

Sorry if this is a totally dumb question, but I can’t seem to find the answer
out there. I was hoping to try and leverage the deploy resource for a simple
app I’ve got in git. I’ve been through the docs at
http://docs.opscode.com/resource_deploy.html and I have things working for the
most part.

The question I have is about expected behavior. It appears that every single
chef run the resource is taking action (including restarting the app) despite
the fact that no changes are pushed to the github repo. We run Chef client on a
schedule, so I’d hate to have the app “deployed” every time chef runs.

So my question is if this is expected or am I doing something wrong? On the
surface this sure doesn’t feel very idempotent, and given the general push to
ensure resources are idempotent this caught me a little of guard.

Here is the uber basic recipe:
deploy “/my/path” do
repo "git://my_git/my_org/my_app.git"
migrate false
symlink_before_migrate({})
restart_command "service httpd restart"
end

Log Entries:
INFO: Processing deploy[/my/path] action deploy (cookbook::default line 15)
INFO: deploy[/my/path] copied the cached checkout to
/my/path/releases/20130313024211
INFO: deploy[/my/path] made pre-migration symlinks
INFO: deploy[/my/path] purged directories in checkout log, tmp/pids,
public/system
INFO: deploy[/my/path] created directories before symlinking tmp,public,config
INFO: deploy[/my/path] linked shared paths into current release: system =>
public/system, pids => tmp/pids, log => log
INFO: deploy[/my/path] made pre-migration symlinks
INFO: deploy[/my/path] linked release /my/path/releases/20130313024211 into
production at /my/path/current
INFO: deploy[/my/path] updated symlinks
INFO: deploy[/my/path] restarting app
INFO: deploy[/my/path] removing old release /my/path/releases/20130313022329
INFO: deploy[/my/path] deployed to /my/path


#4

Geez I’m blind… The doc couldn’t be much more clear on the matter…
“The timestamped_deploy provider is the default deploy provider”…
“Because the timestamp is different for every Chef run, the
timestamped_deploy provider is not idempotent”

Thanks for setting me straight :slight_smile:

On Tue, Mar 12, 2013 at 11:13 PM, Graham Christensen graham@grahamc.comwrote:

Oops - I meant to include a link to the documentation. Here it is:
http://docs.opscode.com/resource_deploy.html#deploy-revision


Graham Christensen

On Tuesday, March 12, 2013 at 11:12 PM, Graham Christensen wrote:

Hi David,

When using the timestamp deploy mechanism (putting the releases in a
structure like this: /my/path/releases/20130313024211) it prevents Chef
from being idempotent.

Try switching to the deploy_revision strategy.

Graham


Graham Christensen