With the chef, how to execute "resource 1" before "resource 2", subject to the fulfillment of "resource 2"?

Question

I have a cookbook with several recipes that sets the service. How the chef client works, it converges every 15 minutes (or some other regular interval). Now the first step in my cookbook is to stop the service, so the service will stop every 15 minutes, but I really want to avoid it. The problem is that maintenance needs to be stopped to complete some steps.

If I had only one or two conditions in the resources of my recipes, I could just do:

condition1 = ... # some true/false values condition2 = ... # service myservice do only_if { condition1 or condition2 } action :stop end resource1 do only_if { condition1 } end resource2 do only_if { condition2 } end 

But since I have a dozen or so conditions in a few recipes, it becomes inelegant. Is there a way to do what this pseudo code does?

 service_resource = service myservice do # somehow don't execute this right now, but wait for # signal from resource1 or resource2 action :stop end resource1 do make sure service_resource executed first only_if { condition1 } end resource2 do make sure service_resource executed first only_if { condition2 } end 

If the chef had some kind of “notify: before” mechanism, and instead of it “notifies: immediately”), I could use this, but I did not find anything like it. Any ideas?

EDIT:

After thinking about it, another way to do this, which is not yet ideal, but better, is to use the chef's compilation phase by specifying the same attribute that has been overwritten. Thus, at least we do not need to keep all conditions in one place.

 # in an "attributes" file: default["stop_service"] = false # in some recipe: service myservice do action :stop only_if { node["stop_service"] } end # ... later, or in some other recipe file condition1 = ... # true/false if condition1 # I think this executes before the only_if of the "service" resource override["stop_service"] = true end resource1 do only_if { condition1 } end 

Answer 1

What will i do:

Configure the configuration in the "intermediate" location, if it is a change, a stop notification, file copying, service start.

Something along the line:

 service "my_service" do action :nothing end template "/staging/conf1" do [... usual attributes ...] notifies :stop,"service[my_service]",:immediately end template "/staging/conf2" do [... usual attributes ...] notifies :stop,"service[my_service]",:immediately end remote_file "/opt/my_service/etc/conf1" do source "/staging/conf1" notifies :start,"service[my_service]" # delayed here to allow all conf files to be updated. end remote_file "/opt/my_service/etc/conf2" do source "/staging/conf2" notifies :start,"service[my_service]" # delayed here to allow all conf files to be updated. end 

My personal taste goes into a cycle on hashes of determining files / templates for this type of parameters with the same resources as:

 node['my_namespace']['conf_files']['conf1'] = "template1" node['my_namespace']['conf_files']['conf2'] = "template2" 

and then going through

 node['my_namespace']['conf_files'].each do |cfgfile,tmplname| template "/staging/#{cfgfile}" do source tmplname notifies :stop,"service[my_service]",:immediately end remote_file "/opt/my_service/etc/#{cfgfile}" do source "/staging/#{cfgfile}" notifies :start,"service[my_service]" end end 

For more complex use cases, you can use a hash instead of a single value.

If more than 2 resources are involved (executing certain commands for the conf file to check it before replacing the actual one, etc.), the definition may correspond.

Another may be to do all the intermediate work in load_current_resource LWRP, but I can go too far for the described use case.