Dependancy order problem

Chefs,

So I just got bit by a problem (on my staging server luckily) where after rebooting a host the Chef tried to restart the nginx server before writing out the new config. But it wouldn’t start since it has an error in the config, so stopped before it wrote out the corrected config…

The service definition was

service “nginx” do
supports :status => true, :restart => true, :reload => true
action [ :enable, :start ]
end

Then later on I (would have) writen /etc/nginx/sites-enabled/myapp.com via a template:

nginx_site proxy_type do
source "proxies/#{proxy_type}.erb"
variables cfg
end

nginx_site has a

notifies :reload, resources(:service => “nginx”)

in it.

Thoughts? How do i fix this kind of problem without manually going in and fixing the config?

Cheers,
-ash

On Tue, Dec 28, 2010 at 8:48 AM, Ash Berlin ash_opscode@firemirror.com wrote:

So I just got bit by a problem (on my staging server luckily) where after rebooting a host the Chef tried to restart the nginx server
before writing out the new config. But it wouldn't start since it has an error in the config, so stopped before it wrote out the corrected config...

I've gotten into this state with Apache too. Getting out of it is even
easier now with the new resource notification syntax [1]. I used to do
something like this:

service "apache2" do
action :enabled
end

template "/etc/apache2/sites-enabled/foo" do
source "foo"
owner "root"
group "root"
mode "0644"
notifies :reload, resources(:service => "apache2")
end

service "apache2" do
action :start
end

In chef, resources of the same name stack. So anything unique you put
into the first service definition is going to still be a part of the
object when you call it later.

Since 0.9.10 there is a new notification syntax that is part of a
pre-parser so you don't need to define the service before you have a
notification.

template "/etc/apache2/sites-enabled/foo" do
source "foo"
owner "root"
group "root"
mode "0644"
notifies :reload, "service[apache2]"
end

service "apache2" do
action [ :enabled, :start ]
end

Bryan

[1] http://wiki.opscode.com/display/chef/Resources#Resources-Notifications

On 28 Dec 2010, at 17:29, Bryan McLellan wrote:

On Tue, Dec 28, 2010 at 8:48 AM, Ash Berlin ash_opscode@firemirror.com wrote:

So I just got bit by a problem (on my staging server luckily) where after rebooting a host the Chef tried to restart the nginx server
before writing out the new config. But it wouldn't start since it has an error in the config, so stopped before it wrote out the corrected config...

I've gotten into this state with Apache too. Getting out of it is even
easier now with the new resource notification syntax [1]. I used to do
something like this:

service "apache2" do
action :enabled
end

template "/etc/apache2/sites-enabled/foo" do
source "foo"
owner "root"
group "root"
mode "0644"
notifies :reload, resources(:service => "apache2")
end

service "apache2" do
action :start
end

In chef, resources of the same name stack. So anything unique you put
into the first service definition is going to still be a part of the
object when you call it later.

Since 0.9.10 there is a new notification syntax that is part of a
pre-parser so you don't need to define the service before you have a
notification.

template "/etc/apache2/sites-enabled/foo" do
source "foo"
owner "root"
group "root"
mode "0644"
notifies :reload, "service[apache2]"
end

service "apache2" do
action [ :enabled, :start ]
end

Bryan

[1] http://wiki.opscode.com/display/chef/Resources#Resources-Notifications

Hmmm i might also be able to do this:

n = service "nginx" do
action [ :enable ]
end

n.notifies :start, n

Which just has the effect of delaying the start till the end of the run (I think.) Thoughts?

-ash

On Tue, Dec 28, 2010 at 9:43 AM, Ash Berlin ash_opscode@firemirror.com wrote:

Hmmm i might also be able to do this:

n = service "nginx" do
action [ :enable ]
end

n.notifies :start, n

Which just has the effect of delaying the start till the end of the run (I think.) Thoughts?

Totally, you got the idea. TMTOWTDI.

Once upon a time we did something like this in the apache2 cookbook:

r = service "apache2" do
action :enable
end

r.updated = true
r.notifies(:start, r, :delayed)

Here is the current version of the evolution of the examples I have given:

https://github.com/opscode/cookbooks/blob/master/apache2/recipes/default.rb

You'll notice that we define the apache2 service pretty heavily early
on, but don't try to start it until the very end of the recipe.

Bryan