On Thu, Jun 9, 2011 at 1:22 PM, Josh Cooper <[email protected]> wrote:
> > One use of pre commands that isn't solved with stages is to check "Should > I > > even do a Puppet run right now?" or anything else that is out of band in > a > > similar sense. > > This makes complete sense and is how the feature was intended to work, > but unfortunately, it never has worked that way (for the agent). > Currently, if the prerun command fails, puppet will attempt to apply > the catalog. Puppet will also always attempt to send a report (due to > #1054), which partially breaks the "master under too much load" use > case. > > So there are several ways in which pre/post run failure states can be > handled. I'm curious to think what you think the default behavior > should be and whether you would like to see these other failure states > supported: > > If the prerun_command fails: > > 1. Ignore the failure, continue applying the catalog, send the report, > etc. > 2. Stop puppet, don't apply the catalog, don't send the report, and > exit(1) > 3. Stop puppet, don't apply the catalog, but do send the report, > including information about why the prerun command failed, and exit(1) > 3. We shouldn't ask the master to compile a catalog or sync facts, but we should report. In some cases the report server isn't the same as the master. As you say 1) is easily achieved. > > #1 is the current behavior, but could also be accomplished by > appending "|| true" to the prerun_command option, e.g. prerun_command > = /bin/meow || true. > #2 was how the feature was originally implemented and how it is > documented, but due to the merge with #1054, the default behavior was > changed to #1. > #3 can also be accomplished using stages. This would be best used in > cases where the prerun command should be "in-band" and its failure > should affect the overall report status, resource_statuses, metrics, > etc. > > I'd like to propose that we change the default behavior for > prerun_command to #2 and document how to accomplish #1 and #3. > > Similarly, if the postrun command fails, there are several different > options: > > 1. Ignore the failure, send the report with whatever status resulted > from applying the catalog, etc. > 2. Stop puppet, don't send the report (even though the catalog may > have been applied), and exit(1) > 3. Add the postrun command error to the report, change the report > status to "failed", etc., and exit(1) > > #1 can be accomplished by appending "|| true" to the postrun_command > option. > #2 is the current behavior. > #3 ideally could be handled using stages, but there is no way > currently to ensure a stage is run. > > I'm not sure what the default should be here. For example, if the > postrun command "/sbin/iptables -A rule" fails, should the report have > a "failed" status? If we don't send the report, will you ever know, > will you care? > > We had a chat about this in person, and my feeling is that the postrun command shouldn't change the status of the run (as it's already complete), but the stdout/err/status should be captured in the report if possible. If you want a command to change the status of the run, it can be an Exec in a final Stage. -- Nigel Kersten Product, Puppet Labs @nigelkersten -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
