service "tomcat7" do
service_name "tomcat7"
action :start
subscribes :create, resources(:template =>
node['pam_limits']['config']), :immediately
end
When I tried to run it, I got expected error:
Cannot find a resource matching template[/etc/security/limits.conf] (did you
define it first?)
I presume node['pam_limits']['config'] is set to
"/etc/security/limits.conf", do you have a template
"/etc/security/limits.conf" in another recipe that runs before-hand?
You'll want to use the newer notification syntax, because it supports
looking up resources that haven't been created yet in the run.
On Thu, Jan 24, 2013 at 3:38 PM, AJ Christensen aj@junglist.gen.nz wrote:
The resource for the template needs to be created before the service
is instantiated, using that syntax for subscribes.
If you use the newer syntax, this restriction does not apply e.g.;
subscribes :create, "template[#{node['pam_limits']['config']}]",
:immediately # I think this will work
It looks like you're missing the 'include_recipe' that creates the
node['pam_limits']['config'] template, anyway..
Indeed, thanks so much! include_recipe was missing.
Now question about order of execution. How can I guarantee that
/etc/security/limits.conf will be rendered before many services which are
"consuming" it?
Let's say that I have Oracle DB and Tomcat installed on that host and both
of them are needed to fix /etc/security/limits.conf for various options.
If I setup :immediately in subscribe that it's too early. But if I specify
:delay than my action (:restart) will be processed as last step during
chef-client run.
I actually doesn't need to do anything after limits.conf update, I just
need to ensure that no dependent service in various recipes will be run
before limits.conf have updated data.
Now question about order of execution. How can I guarantee that
/etc/security/limits.conf will be rendered before many services which are
"consuming" it?
Let's say that I have Oracle DB and Tomcat installed on that host and both
of them are needed to fix /etc/security/limits.conf for various options.
If I setup :immediately in subscribe that it's too early. But if I specify
:delay than my action (:restart) will be processed as last step during
chef-client run.
I actually doesn't need to do anything after limits.conf update, I just
need to ensure that no dependent service in various recipes will be run
before limits.conf have updated data.
Unfortunately Chef does not have a good answer for this. We have several
strategies to deal with this.
In a dream world you would be able to tag a notification with a key and
then later sync all notifications with that key. Something like
['a','b','c'].each do |f|
file "/opt/jenkins/workspace/jobs/#{f}.xml" do
content "...."
notifies :restart, "service[jenkins]", :delayed, :sync_on =>
"jenkins.sync"
end
end
Ensure all notifications with "jenkins.sync" are invoked
sync_notifications "jenkins.sync"
By this stage jenkins has restarted
jenkins_cli "do something here"
However, until such a capability is added to chef you have to do some crazy
things. For the above scenario, we created a LWRP that used the "
notifying_action" pattern to ensure that the notifications are resolved at
the end of the LWRP. See [1] for an example.