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.

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.

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.