Hello all,
First post, so pass if it out-of-scope…
The title of this thread is what I used to try to find my own answer in Google…responses in the form of better queries are fine by me! :0)
—> I have a remote_file block followed by a file block, and I need to add a guard, but the remote_file block also notifies other actions:
remote_file “#{Chef::Config[:file_cache_path]}/#{node[:prodname][:deploy_war][:app_name]}.war” do
source node[:prodname][:war_source]
mode "0755"
use_conditional_get true
notifies :stop, “service[#{node[:tomcat][:service]}]”, :immediately
notifies :delete, “directory[#{node[:prodname][:deploy_war][:app_dir]}]”, :immediately
notifies :delete, “file[#{node[:prodname][:deploy_war][:deployed_war_file]}]”, :immediately
end
file “#{node[:prodname][:deploy_war][:deployed_war_file]}” do
content lazy { IO.read(node[:prodname][:deploy_war][:downloaded_war_file]) }
owner "root"
group "root"
mode "0755"
notifies :restart, “service[#{node[:tomcat][:service]}]”, :immediately
end
Here’s the problem: I am thinking to allow the remote_file block to execute, and then I can compare checksums of the previously downloaded warfile before the notify deletes it.
I am thinking that a LWRP that just handles the notifies, inserted between these two blocks, would allow me to do my comparison, and to stop action if there was no change.
—> What sort of LWRP would you recommend for this usage?
I could exec “echo foo” and put the notifies in it, but with a guard that does my check…but what is the best practice in this instance?
This was way too long…thanks to all who got here.
Christopher
P.S. I need to learn markdown…I did not mean to shout above!
---->and arrow with a line of ='s below
???
This worked fine:
execute “echo foo then notify things” do
command "echo FOO!"
notifies :stop, “service[#{node[:tomcat][:service]}]”, :immediately
notifies :delete, “directory[#{node[:prodname][:deploy_war][:app_dir]}]”, :immediately
notifies :delete, “file[#{node[:prodname][:deploy_war][:deployed_war_file]}]”, :immediately
not_if ( “diff #{Chef::Config[:file_cache_path]}/#{node[:prodname][:deploy_war][:app_name]}.war node[:prodname][:deploy_war][:deployed_war_file]}” )
end
I just inserted in between the two blocks, I put the notifies into the next block, and
then I added a guard on the new block.
I was just wanting to know what was best practice here.
Take care,
Christopher
On Friday, October 23, 2015 at 4:55 AM, chahn1138 wrote:
ugh, Discourse doesn’t seem to understand anything other than top posting. Anyway:
This is probably fine. A ruby block would probably be slightly more efficient since it won’t spawn an extra shell to run ‘echo’, but on 2015 hardware the difference will likely not be noticeable.
The architecturally “best” solution would be to wrap up all of the behaviors of your tomcat service into a custom resource. If you’re using Chef 12.5 this is a lot easier than it was before, you can see the docs here: https://docs.chef.io/custom_resources.html
That said, if the code you have now gets the job done, it might not be worth your time to rewrite it in the name of architectural perfection.
Thank you for taking the time.
…that was very much the sort of answer I was hoping for…
LOL, “ruby_block”, yes, this sounds like the “even-less-op” that I was looking for.
No, we are not on that version of Chef, but I appreciate another reason to argue
for an upgrade. I will consider your approach in any case.
Take care,
Chris
The pattern that people have been using for no-ops is to use:
log "notifying lots of things" do
notifies :stop, "service[#{node[:tomcat][:service]}]", :immediately
notifies :delete, "directory[#{node[:prodname][:deploy_war][:app_dir]}]", :immediately
notifies :delete, "file[#{node[:prodname][:deploy_war][:deployed_war_file]}]", :immediately
not_if ( "diff #{Chef::Config[:file_cache_path]}/#{node[:prodname][:deploy_war][:app_name]}.war node[:prodname][:deploy_war][:deployed_war_file]}" )
end
We probably need some kind of ‘null’ resource that literally does nothing other than become updated and trigger notifies like this.
1 Like
I really appreciate that alternative. Thank you for the time.