[chef] Re: Re: Re: notifications / subscribe: different cookbook

[Peter Donald < >]

Hi,

On Fri, Jan 25, 2013 at 11:22 AM, Andrey Brindeyev < " target="_blank"> > wrote:

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.

Other than that there is no easy way I know of.

[1] https://github.com/realityforge/chef-jenkins/blob/master/providers/config_set.rb

--
Cheers,

Peter Donald