Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Return runner return code in a way compatible with check_state_result #39641

Merged
merged 1 commit into from Feb 24, 2017

Conversation

smarsching
Copy link
Contributor

@smarsching smarsching commented Feb 24, 2017

What does this PR do?

This PR changes how a runner returns return code that should be returned on the command-line. Before this change, it was returned in ret['data']['retcode'], after the change it is returned in ret['retcode']. The code in salt/cli/run.py was changed in a way so that it can still deal with runners using the old format. The only runner in the core distribution (salt.orchestrate) is also changed by this PR so that it uses the new format.

What issues does this PR fix or reference?

This PR fixed #39169. The problems described in #39169 happended when a runner (currently only state.orchestrate) included a return code in the ret['data'] dict. When ret['data'] was later processed by check_state_result, the check failed because ret['data']['retcode'] is an integer and not a dict, but only dicts are expected as values in ret['data'].

Previous Behavior

salt-run expected a runner to return an (optional) return code in ret['data']['retcode']. state.orchestrate used this feature.

New Behavior

salt-run expectes a runner to return an (optional) return code in ret['retcode'], but will fall back to ret['data']['retcode'] if ret['retcode'] is not present. state.orchestrate uses the new format.

Tests written?

No

Previously, the return code of the runner (if any) was supplied in
ret['data']['retcode']. This was problematic if ret['data'] was later processed
by check_state_result. With this change, runners return the optional return
code in ret['retcode'], like the other code (modules, etc.) already did before.
@ghost
Copy link

ghost commented Feb 24, 2017

@smarsching, thanks for your PR! By analyzing the history of the files in this pull request, we identified @anttix, @isbm and @s0undt3ch to be potential reviewers.

@smarsching smarsching changed the base branch from develop to 2016.3 February 24, 2017 12:14
@smarsching
Copy link
Contributor Author

Sorry, for the mess. I accidentally hit the return key, so the PR was created before I had put in all data. I made this PR against 2016.3 because it is the earliest release that has the bug, but I also have a patch against the develop branch, in case you prefer that one.

@smarsching smarsching changed the title Fix for 39169 2016.3 Return runner return code in a way compatible with check_state_result Feb 24, 2017
@isbm
Copy link
Contributor

isbm commented Feb 24, 2017

@smarsching does tests pass?

@smarsching
Copy link
Contributor Author

smarsching commented Feb 24, 2017

I finally managed to install all the dependencies needed to run the tests. Running the tests took ages and a few of them failed:

FAILED (total=5388, skipped=665, passed=4715, failures=5, errors=3)

I do not think that these failures are related to my changes (e.g. unit.modules.timezone_test.TimezoneTestCase.test_get_zone failed), but of course it would be better to have all running.

I just saw that in the meantime, Jenkins has also finished running and the checks have passed, so I guess the changes are okay.

@isbm
Copy link
Contributor

isbm commented Feb 24, 2017

@smarsching Naw, only related tests to this. Particularly from my PR, I've mentioned in the issue earlier. Does it still passes?

@smarsching
Copy link
Contributor Author

I will check that. However, it might be a while because I just completely messed up my test VM and have to restore it from a backup... 🤦‍

@smarsching
Copy link
Contributor Author

So unit.utils.utils_test passes (this is the one referenced in #31745) and all of the runner tests pass as well, so I guess we are fine.

@isbm
Copy link
Contributor

isbm commented Feb 24, 2017

Seems OK. @cachedout seems we are clean. Merge?

@cachedout
Copy link
Contributor

@isbm Yup, I agree. This looks good.

@cachedout cachedout merged commit f7389bf into saltstack:2016.3 Feb 24, 2017
@hoffmannliu-ayla
Copy link

Looks like 2016.11.4 includes PR#39641 for 2016.3. I will see if this one is fixed in 2016.11 now.

@smarsching smarsching deleted the issue-39169-2016.3 branch December 9, 2022 23:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants