Fix plan return value #209
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
reidmv
force-pushed
the
fix-plan-return-value
branch
4 times, most recently
from
80c936d
to
2a5e8b1
Compare
MikaelSmith
approved these changes
Jun 10, 2019
|
Thanks for submitting the PR @reidmv . |
|
@reidmv The testcases ran clean on all platform except the redhat8.Thank you. |
|
Just noticed there's still a Will work on fixing that and updating PR shortly... |
reidmv
force-pushed
the
fix-plan-return-value
branch
from
492dafe
to
009a08a
Compare
|
Updated PR. Should be good to go now. |
reidmv
force-pushed
the
fix-plan-return-value
branch
from
009a08a
to
2e7e186
Compare
Prior to this commit the reboot plan raised an error calling max() without a valid argument. This commit causes the plan to short-circuit and return an empty ResultSet in the event an empty TargetSpec was given as the $nodes argument. Long-term, the plan should probably be modified to always return a meaningful ResultSet value on completion.
Assuming some nodes successfully reboot and some nodes don't, when the reboot plan is invoked with _catch_errors => true, it should return meaningful data so that the end user can decide how to handle or report on which nodes failed to reboot while potentially continuing forward to another task with the set of nodes that succeeded. This commit makes the reboot plan always return meaningful data, even when erroring. Side note: gonna open a ticket to make it easier to _catch_errors for a plan, for the end user...
A common use case for using the reboot plan with _catch_errors => true would be to review which systems didn't reboot and remediate or move forwards only with those that did. However, even with _catch_errors => true, the caller has to check if the plan result is an error and go down a different code path if so to deal with it and extract the ResultSet they need. This commit provides a new Boolean plan option, fail_plan_on_error, which if set to false will ensure the plan always returns exactly the same data type regardless of whether or not any individual target failed to reboot. The consuming plan author can then simplify their own code, secure in the knowledge of what kind of data will be returned.
This commit fixes a missed fail_plan() invocation that would have allowed a plan to fail even if fail_plan_on_errors was set to false. In doing so, it further linearizes the logic, allowing for a slight simplification of the main reduce function. While making the commit, it seemed like a good idea to restore the fail_plan() detail key that was used previously, in order to retain compatibility with previous failure return results. Clean up the spec test a bit while in here.
reidmv
force-pushed
the
fix-plan-return-value
branch
from
2e7e186
to
2a35d87
Compare
|
@reidmv Thanks for the quick turn around. Will rerun the ad-hoc jobs. |
|
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Assuming some nodes successfully reboot and some nodes don't, when the
reboot plan is invoked with
_catch_errors => true, it should returnmeaningful data so that the end user can decide how to handle or report
on which nodes failed to reboot while potentially continuing forward
to another task with the set of nodes that succeeded.
This commit makes the reboot plan always return meaningful data, even
when erroring.