Closed Deshke closed 5 years ago
"Unable to render top file" is working for me via salt-ssh, which calls salt-call internally. This is based on a pull request I did a while ago.
Version: 2016.3.2
salt-ssh -i 'foo.acme.com' state.highstate
[ERROR ] Unable to render top file: while parsing a block mapping
in "<unicode string>", line 1, column 1:
base:
^
expected <block end>, but found '<block sequence start>'
in "<unicode string>", line 4, column 5:
- base
^
foo.acme.com:
Summary for foo.acme.com
-----------
Succeeded: 0
Failed: 0
-----------
Total states run: 0
[ngrennan@host _ssh_master_dev]$ echo $?
20
'*'
vs '*':
in top.sls
ZD-1502 & ZD-935
Wait, what is the current status of retcodes for salt operations? It's been 4 years since the issue was created...
Exit codes have been normalized in https://github.com/saltstack/salt/pull/48361 for the upcoming Fluorine release. The following conditions will set a nonzero exit code:
__context__['retcode']
to a nonzero valueresult
or success
key in it, which resolves as False
file.file_exists
would not trigger any of those conditions, however. The problem here is if we use something like __context__['retcode']
in file.file_exists
to denote failure, then we've marked the run as failed, so if any state invokesfile.file_exists
, this would make salt reutrn a nonzero exit code even if the file not existing was expected (and therefore not an error).
I'm a bit confused about the status - I've just picked up salt 2018.3.4
which has the latest fixes in for return codes for salt-call
. If I pass the argument --retcode-passthrough
to salt-call
I now get non-zero exit codes for failures but without it I always get 0 - is this the expected functionality at the current time? Anybody know when this functionality becomes the default?
I think this is expected, as far as I know. To get status code from operation executed by salt-call you have to use --retcode-passthrough
if nothing was changed.
@oliver-dungey As explained above, the retcode changes are in the Fluorine release (2019.2.0).
@saltstack/team-core Since Fluorine was released, this can be closed.
Using salt version below, the issue with the incorrect exit code is still present when you add --batch-size and --batch-wait parameters
Salt Version:
Salt: 2019.2.0
Dependency Versions:
cffi: 1.6.0
cherrypy: unknown
dateutil: Not Installed
docker-py: Not Installed
gitdb: 0.6.4
gitpython: 1.0.1
ioflo: Not Installed
Jinja2: 2.7.2
libgit2: 0.26.3
libnacl: Not Installed
M2Crypto: 0.31.0
Mako: Not Installed
msgpack-pure: Not Installed
msgpack-python: 0.5.6
mysql-python: Not Installed
pycparser: 2.14
pycrypto: 2.6.1
pycryptodome: 3.7.3
pygit2: 0.26.4
Python: 2.7.5 (default, Apr 9 2019, 14:30:50)
python-gnupg: Not Installed
PyYAML: 3.11
PyZMQ: 15.3.0
RAET: Not Installed
smmap: 0.9.0
timelib: Not Installed
Tornado: 4.2.1
ZMQ: 4.1.4
System Versions:
dist: centos 7.6.1810 Core
locale: UTF-8
machine: x86_64
release: 3.10.0-957.5.1.el7.x86_64
system: Linux
version: CentOS Linux 7.6.1810 Core
sudo salt -v -L minion-1,minion-2 --batch-size 50% --batch-wait 1 state.apply queue=True test-state
Even though there is an error:
jid:
20190613124535690469
retcode:
1
gc-euw1-salt-1:
Data failed to compile:
----------
Rendering SLS 'base:test-state' failed: Jinja syntax error: expected token 'end of statement block', got 'string'; line 1
salt exit status is 0.
echo $?
0
Please open a new issue. Commenting on a closed issue doesn't do much good.
is there a reason why test.* returns False and exits with bash exit code 0 instead of 1 ?