On Tue, Sep 17, 2013 at 7:26 AM, Rob Reynolds <[email protected]> wrote:
> 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? > > I think go for A, and leave out the property. Option A is the normal puppet semantics (the resource didn't fail, other unrelated things did). If it turns out that there are actual cases that users reach where they need to stop the reboot because unrelated problems happen, then we can add in the feature, but I think we should take a bit of an opinionated stance at first and modify that as real uses are found. > > On Tue, Sep 17, 2013 at 2:10 AM, Josh Cooper <[email protected]> wrote: > >> >> >> >> On Mon, Sep 16, 2013 at 4:19 PM, badgerious <[email protected]> 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 [email protected]. >>> To post to this group, send email to [email protected]. >>> 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 [email protected]. >> To post to this group, send email to [email protected]. >> 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 [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/puppet-dev. > For more options, visit https://groups.google.com/groups/opt_out. > -- Andrew Parker [email protected] Freenode: zaphod42 Twitter: @aparker42 Software Developer *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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-dev. For more options, visit https://groups.google.com/groups/opt_out.
