salt-call state.highstate should optionally use exit codes to report failures

[stevearc]

This was mentioned on the google group a few months ago, but I don't believe the original poster ever created an issue for it.

When I call salt-call state.highstate, I would like the exit code to be nonzero if any of the states fail.

[thatch45]

This was covered elsewhere, and I have previously stated, that the exit code declared that the salt execution completed successfully.
With that said, we have had a lot of demand for this, so I will explore it when time permits.

[sebw]

Any update on this ? I'm currently testing Jenkins monitoring for highstates and everything reports as successful.

[basepi]

Right, as @thatch45 mentioned, the exit code just represents that the salt execution completed successfully. We might be able to set an option to change that behavior or something, but it's not something we've had time to explore yet.

[jMyles]

Like @sebw , I'm using jenkins to run salt-call. Is there a workaround for now? Is there anything we can do to accelerate this?

[jMyles]

This workaround is working for me for the moment.

*I have added "-l error --log-file=./minion-errors" to the salt call.
*Then, in a bash script:

if [ -s minion-errors ]
then
  rm minion-errors
  exit 1
else
  rm minion-errors
  exit 0
fi

[basepi]

Glad you found a workaround. =)

[zxwing]

Any timeline on this feature? this is very key to thridparty system which wants to integrate with salt.
Missing it seems a major design flaw.

[basepi]

We don't currently have a timeline, but thanks for bumping this. I've put it on the current milestone so more eyes will hit it.

[techdragon]

adding more weight on to this. I'm currently having to spend a LOT of time working around this 'missing feature'. :-(

[grantmcwilliams]

I am auto provisioning keys and need to know if the salt-minion has connected to the salt-master. I was trying a test.ping but salt returns 0 no matter what.

I then got the bright idea of using salt.cmd to run a command on the minion. If the minion doesn't exist I get an rc of 2. If it does exist but salt-minion isn't running I get a 0. So according to salt not being able to contact a salt-minion is still a success.

This is a show stopper for me. I'll contribute code if necessary but I need to have some way to determine if a salt call was successful or not.

[bmurphy1976]

+1

[rgbkrk]

For salt, the exit code returning that salt execution completed succesfully makes sense.

When using salt-call though, it should definitely return an appropriate return code since it's running on just one box.

Is anyone currently working this in a branch? If we get something implemented for salt-call at a minimum, I'll help improve the environment for those wanting to test states, modules, etc. on Travis CI.

[whiteinge]

@rgbkrk I just learned this has been added to salt-call as an optional flag: --retcode-passthrough. (Woot!)

[rgbkrk]

Awesome, thanks @whiteinge!

[rgbkrk]

Created a failed build on purpose using the retcode passthrough - https://travis-ci.org/rgbkrk/salt-states-nbviewer/builds/17884043. Success!

[rgbkrk]

The only strange thing here is that it lists a different return code than is actually returned.

The command "sudo salt-call state.show_lowstate --local --retcode-passthrough" exited with 0.
Done. Your build exited with 1.

In reality, I don't care because I just need travis to know about minion success. This is great!

[techdragon]

Yet another issue associated with #7013
Need to confirm that retcode passthrough passes through the correct code since the last comment from @rgbkrk sounds like while it 'works' for him, it doesnt behave as expected meaning either clarification, a docfix, or bug needs doing.

[rgbkrk]

@techdragon You're absolutely correct. An issue needs to be opened and a pull request needs to be submitted!

[jforest]

I will add my 2 cents to this as well, it's definitely wrong on it's return states:

Here is what is run:

docker run -v $WORKSPACE/salt:/srv/salt:ro -v $WORKSPACE/pillar:/srv/pillar blah/test /usr/bin/salt-call --local --retcode-passthrough state.sls resolv
RETCODE=$?
echo "return code: ${RETCODE}"

and the output:

Summary
Succeeded: 6
Failed: 0
Total: 6
return code: 2

If I run without the --retcode-passthrough:

docker run -v $WORKSPACE/salt:/srv/salt:ro -v $WORKSPACE/pillar:/srv/pillar blah/test /usr/bin/salt-call --local state.sls resolv
RETCODE=$?
echo "return code: ${RETCODE}"

Summary
Succeeded: 6
Failed: 0
Total: 6
return code: 0

[techdragon]

Perhaps we can get a more 'robust' test case around this function to work against. A set of salt calls that should return various exit codes with retcode-passthrough.

[kiorky]

Please see PR #10504

[techdragon]

I think this can be closed as fixed by #11337

[basepi]

Awesome!

[perdurabo93]

Which release will this be merged in?

[basepi]

2014.7.0. It's in feature freeze now, and will have a release candidate hopefully in the next week.

[mschiff]

This still does not seem to be imlpemented, or am i missing something?

[damon-atkins]

Their needs to be at least 3 exit codes.
0 All was perfect and as expected (could do everything asked)
1 Could not talk to the salt master
2+ You should parse the output to determine the issue
3-126 maybe some more specific errors.

For example a bit and could be used 4,8,16,32,64
4 Not all minons could be communicated with

[curiositycasualty]

Still perplexed, moreso after looking at https://github.com/saltstack/salt/blob/develop/salt/defaults/exitcodes.py

I have a highstate that has 2 failing states. When run with --retcode-passthrough, the highstate returns with an exit code of 143...?

Summary for local
--------------
Succeeded: 246 (changed=86)
Failed:      2
--------------
Total states run:     248
Total run time:   129.400 s
Terminated
highstate retcode: 143