So far it sounds like option A, but I think there was a thought started here that you could just order everything so that the reboot occurs last. Then if there is an issue along the way, the next run (provided it doesn't also error) will cause the reboot to happen.
Which could technically meet both approaches. But perhaps we could add a `continue_on_catalog_error => true` as default. Then someone can make that decision themselves. Thoughts? On Tue, Sep 17, 2013 at 2:10 AM, Josh Cooper <j...@puppetlabs.com> wrote: > > > > On Mon, Sep 16, 2013 at 4:19 PM, badgerious <badge...@hotmail.com> wrote: > >> If we support this functionality and there is a failure during the >>> catalog run after a reboot at the end has been requested, what would be >>> your expectation for the system. >>> >> >>> Would you expect it to: >>> >> >>> A) still reboot >>> >> B) not reboot >>> >> C) something else (please comment) >> >> >> I vote A. As I understand it, skipping the reboot means throwing it into >> the oblivion; there's no way for the next puppet run to pick the reboot up >> because the event triggering it probably won't occur again. >> > > If a notify/subscribe relationship causes a reboot to be scheduled, but is > not performed due some other resource failing, then the event will be lost. > This is a general problem with events in puppet actually[1]. > > If puppet detected that a reboot is pending, e.g. > HKLM\SYSTEM\CurrentControlSet\Control\Session > Manager\PendingFileRenameOperations, and a reboot is scheduled, but not > performed for same reasons as above, then puppet should reschedule the > reboot the next time it runs (assuming the catalog remains the same). > > >> I've had plenty of small, inconsequential failures and wouldn't want them >> affecting other (reboot requiring) things. >> >> It may be in a state that won't boot cleanly due to the failing half run >>> catalog. >> >> >> I would think that a sequence of steps that may result in an unbootable >> system should be ordered such that the last item is the reboot, which would >> get around that issue. >> >> Eric >> >>> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to puppet-dev+unsubscr...@googlegroups.com. >> To post to this group, send email to puppet-dev@googlegroups.com. >> Visit this group at http://groups.google.com/group/puppet-dev. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > So it sounds like there is agreement on option A? > > Josh > > [1] http://projects.puppetlabs.com/issues/3806 > > -- > Josh Cooper > Developer, Puppet Labs > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-dev+unsubscr...@googlegroups.com. > To post to this group, send email to puppet-dev@googlegroups.com. > Visit this group at http://groups.google.com/group/puppet-dev. > For more options, visit https://groups.google.com/groups/opt_out. > -- Rob Reynolds Developer, Puppet Labs Join us at PuppetConf 2014, September 23-24 in San Francisco -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To post to this group, send email to puppet-dev@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-dev. For more options, visit https://groups.google.com/groups/opt_out.
