[chef] Re: Re: server's reboot action

[John Dewey < >]

I believe this approach would prevent the chef-client from completing.  Thus preventing the node's status from being saved back to the server.  If you were to change it to a shutdown with a delay that would probably work better.

It might be better to use a handler to deal with reboots.  I have a cookbook I was working on that attempted this.   A cookbook which made a change requiring a reboot would set node.run_state['reboot'] to true.  The handler would then deal with rebooting the system if it was set && met some additional criterial.  I am using this to pivot hypervisors interfaces to bonded, before assigning the systems their OpenStack roles.

https://github.com/retr0h/reboot-handler

On Thursday, August 30, 2012 at 12:03 PM, Bryan McLellan wrote:

On Thu, Aug 30, 2012 at 5:31 AM, < "> > wrote:

Just started to work with recipies . How to define server's reboot ?

This is a terrible abuse of resources due to the lack of being able to

trigger a notification as a first class object, but this works for

triggering a reboot toward the end of the run. There is not a way to

control the order of the delayed notifications though, so if you have

notifications that are important this might run before them. Usually

delayed notifications are for services though, and since you're

rebooting anyway, that shouldn't be a problem.

execute "reboot" do

command "reboot"

action :nothing

end

ruby_block "trigger delayed reboot" do

block { true }

notifies :run, "execute[reboot]", :delayed

end