My idea on reboots is different. I don't think we should have puppet do the reboot. If we go down this road, we need autologon, credentials, runonce, and a subsequent puppet agent run among other things. Not ideal if a puppet agent service is running during business time. This is orchestration and not where puppet should not be trying to succeed.
Originally I thought I needed a facter fact to determine if a reboot pending state existed, but the problem is that the facts are determined upfront. So if a resource triggers a "state" where a reboot is needed the fact is busted. I think we need a new embedded construct which can check the reboot state before processing every resource. It has to happen before it makes it to the provider since it should not be left to a provider author as it could apply to any resource. If this boolean goes true then every resource in that graph needs to be skipped. A meta param can be added to say reboot => force which can force a resource to be processed _despite_ the boolean. I also need way to stateful trigger reboot flag like a lockfile so I can do a bios upgrade. Actually _rebooting_ with puppet I am leery of. I welcome all input on this. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
