Just started to work with recipies . How to define server’s reboot ?
Vlad,
However you would do a reboot on the command line, you could do the same in
an "execute" resource.
On Thu, Aug 30, 2012 at 5:31 AM, vlad.berezovski@gmail.com wrote:
Just started to work with recipies . How to define server's reboot ?
On Thu, Aug 30, 2012 at 5:31 AM, vlad.berezovski@gmail.com 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
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, <vlad.berezovski@gmail.com (mailto:vlad.berezovski@gmail.com)> 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
endruby_block "trigger delayed reboot" do
block { true }
notifies :run, "execute[reboot]", :delayed
end