Issue #1633 has been updated by jamtur01. Status changed from Closed to Needs more information
---------------------------------------- Feature #1633: Detailed exit codes for puppet executable http://projects.reductivelabs.com/issues/show/1633 Author: grim_radical Status: Needs more information Priority: Normal Assigned to: jamtur01 Category: executables Target version: 0.24.6 Complexity: Easy Affected version: 0.24.4 Keywords: When puppet (and by this I mean /usr/bin/puppet) runs, it exits with a 0 as long as an exception isn't thrown. It would be handy if the exit code was actualy indicative of what happened during the run. For example, there's currently no way to test, based on the execution of puppet, that any anomalies were actually corrected. And if during a puppet run, say, an exec fails to execute correctly, puppet still exits with a 0. This first come up at my company when we started to wire in puppet with kickstart. I'd like to run puppet at the end of a kickstart, and I'd like it to run "to completion". More aptly put, "we should continue to run puppet until all configuration anomalies have been corrected". Since puppet doesn't give the shell any indication about what it did during its run, we have no way of knowing when we can stop running puppet and finally put the box into service. We run into the same issue when we deploy new versions of our application, which is deployed using puppet. We'd like to write wrappers around puppet that will ensure that it's run "to completion"; this lets us effectively automate the upgrade process and makes it more resilient to failures. Our current workarounds for this are a series of horrible hacks: 1) Our wrapper scripts and kickstart scripts just run puppet N times. This sucks, especially if all configuration problems were corrected on the first run. This massively slows down cluster-wide puppet update operations. 2) Scan the output of the puppet executable. This worked, but this code was extremely brittle and error prone. But the way I figure it, puppet already has the ability to generate a transaction report. It should be straightforward to introspect upon the report object and figure out just what transpired during the puppet run. We're now running a patched version of puppet that does exactly that, and it's worked pretty well so far. I've ported the patches forward to 0.24.x and attached them to the ticket. Patch details: 1) I added a new options to puppet called "--detailed-exitcodes". I'm not taken with the name, but it works. We default to having puppet return the same exit codes it always did. But when you supply that option, we generate a transaction report and look inside it to figure out what happened. 2) For the actual exit status, I'm using a bitmask. Bit 2 (1 being the least significant bit) is a "1" if puppet applied any changes. Bit 3 is a "1" if puppet encountered any failures dealing with resources. 3) It appears that catalog.retrieval_duration isn't set to anything when puppet isn't run in client/server mode. Generating a report will crash because that variable is set to 'nil'. This seems like something worth fixing anyways, because we run puppet in standalone mode but still want reports sent to a reportserver. I wasn't sure what to set this value to in a standalone run, since no config is actually retrieved from anywhere. But rather than set it to zero, I set it to the amount of time required to parse the config. 4) Dealing with Puppet::Util::Metric objects was a little hairy. They appear to be dictionary-esque, but don't support the "[]" operator. I added a tiny method to metric.rb that adds support for that operator, which makes introspection a lot nicer. ---------------------------------------- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://reductivelabs.com/redmine/my/account --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Bugs" 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-bugs?hl=en -~----------~----~----~----~------~----~------~--~---
