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 <[email protected]> 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 <[email protected]> wrote: > >> 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. >> > > > > -- > -- > Ethan Brown > [email protected] > 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 [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.
