Okay, now to introduce my bias into the conversation now that others have responded.
A - always want to reboot even if other unrelated events fail. On Tue, Sep 17, 2013 at 10:54 AM, Ethan Brown <et...@puppetlabs.com> wrote: > Likewise A. > > I was part of the initial discussion earlier yesterday, and to me this > felt like the most pragmatic thing to do under the circumstances. > > > On Tue, Sep 17, 2013 at 10:51 AM, Andy Parker <a...@puppetlabs.com> wrote: > >> On Tue, Sep 17, 2013 at 7:26 AM, Rob Reynolds <r...@puppetlabs.com> 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 <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. >>> >> >> >> >> -- >> Andrew Parker >> a...@puppetlabs.com >> 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 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. >> > > > > -- > -- > Ethan Brown > et...@puppetlabs.com > Software Engineer > > > *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. > -- 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.
