Open 9numbernine9 opened 4 years ago
Thanks for reporting this! I'm thinking that there may have been a code path that has been introduced which leads to reporting this error, or possibly the error message has changed. But I agree, the error message should have a better message.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.
Please keep this issue open, stale-bot. :-)
Thank you for updating this issue. It is no longer marked as stale.
At this time we are unable to allocate resources to this issue, and are planning for the next release cycle to plan and commit.
same issue with a different module: https://github.com/saltstack/salt/issues/55562 - need to fix this broadly, may need input validation, looking to correct this in the Magnesium release
Just to stave off stale bot mainly.
We're running into this as well. We use salt-ssh for a state.apply test=True prior to making our changes live and it's a part of our validation which normally works pretty well.
Hope that helps. We're on 2019.2.4.
$ salt-ssh --versions-report
Salt Version:
Salt: 2019.2.4
Dependency Versions:
cffi: Not Installed
cherrypy: Not Installed
dateutil: 2.4.2
docker-py: 1.9.0
gitdb: Not Installed
gitpython: Not Installed
ioflo: Not Installed
Jinja2: 2.8
libgit2: Not Installed
libnacl: Not Installed
M2Crypto: Not Installed
Mako: Not Installed
msgpack-pure: Not Installed
msgpack-python: 0.4.6
mysql-python: Not Installed
pycparser: Not Installed
pycrypto: 2.6.1
pycryptodome: Not Installed
pygit2: Not Installed
Python: 3.5.2 (default, Apr 16 2020, 17:47:17)
python-gnupg: 0.3.8
PyYAML: 3.11
PyZMQ: 15.2.0
RAET: Not Installed
smmap: Not Installed
timelib: Not Installed
Tornado: 4.2.1
ZMQ: 4.1.4
System Versions:
dist: Ubuntu 16.04 xenial
locale: UTF-8
machine: x86_64
release: 4.15.0-99-generic
system: Linux
version: Ubuntu 16.04 xenial
Earlier version of this message said the file was there, it wasn't but the error message changing would be useful :-)
@zbukhari stale bot was ~beaten into the ground and~ disabled earlier in the year :D and yes, we are looking into this and the salt-ssh state.apply test=True issue for the next major release Magnesium, target date in the fall 2020.
@zbukhari do you know if this issue is present in the most recent 3001 release? I haven't gone looking, but I have a feeling like I've fixed this (or wrote tests for it) somewhat recently :suspect:
Ahhhhhh. I did write some tests: https://github.com/waynew/salt/commit/772fe25beae573587efcc6c3d3d126e3616bad07
I'm guessing that a similar approach needs to happen here. @sagetherage we might be able to do some automagic smoke testing here, but I think fundamentally it's just that certain things are returning the wrong kind of data. There may be someone with a good idea about an approach here, but at least at the moment, I've got nothing.
FWIW contracts in pop/idem would solve this problem 😂
We have to de-scope this for Magnesium, you can see the pop projects in GitLab: https://gitlab.com/saltstack/pop and there are many idem projects, and I am unsure exactly but at least this link gives you a place to start.
Still an issue in salt-2019.2.7
While searching for a solution fo the same error I ran into this issue. Came up with the solution to use onlyif to first check if the source file exists.
copy_somefile:
file.managed:
- name: /srv/www/somefile
- source: /srv/tmp/somefile.dist
- mode: 644
- onlyif:
- fun: file.file_exists
path: /srv/tmp/somefile.dist
I still saw this issue today in 3002.2. Thanks to @9numbernine9 for pointing out what the error would read, fixed my silly mistake.
I also ran into this issue on 3002.5, so it still exists.
In my case the cause was setting up a new salt master on 3002.5, from my git repo of stack/pillar, but forgetting that there are some files deliberately not checked into git which need to be hand copied over from the old master. The resulting error message is very obscure (I only realised quickly when I found this issue) for what should have been "source file not found"; if I'd got "source file not found" I'd have immediately realised what I'd forgotten to do when setting up the new salt server :-)
Ewen
Looks like we didn't get to this work in Aluminium
I will put it into Silicon and get it reassigned
Another error that causes this:
[ERROR] (False, 'Unable to verify upstream hash of source file https://repo.saltproject.io/py3/ubuntu/20.04/amd64/latest/salt-archive-keyring.gpg, please set source_hash or set skip_verify to True')
local:
The State execution failed to record the order in which all states were executed. The state return missing data is:
{'changes': {},
'comment': "An exception occurred in this state: 'Changes' should be a "
'dictionary.',
'name': 'later',
'result': False}
Ran into this a few hours ago. The salt master was unable to access files stored in S3 (secrets were set to dummy values for CI/CD testing) and I got the same output as @9numbernine9 above.
In this example i got this error aswell. The issue was caused by renaming the /salt/base/share to /salt/base/nfs:
nfs_config: file.managed:
Obviously by changing share to nfs the issue was resolved. Just trying to state that the error catching isnt all that yet.
When breaking my own code and rewriting stuff, this issue is still at large:
nfs_config: file.managed:
Dir should be: - source: salt://nfs/export/templates/nfs_export.j2
Ill stop replying to this now. Just pointing out that there should be an error like "change to correct dir in this function"
Still happening
freebsd_vm:
The State execution failed to record the order in which all states were executed. The state return missing data is:
{'changes': {},
'comment': "An exception occurred in this state: 'Changes' should be a "
'dictionary.',
'name': 'later',
'result': False}
@network-shark what version of Salt are you seeing this in or is it also in master
- thanks for the extra help!
Just ran into this error on salt-3001.7 as well
Also seeing this issue
Salt Master:
Salt Version: Salt: 3002.2
Dependency Versions: cffi: Not Installed cherrypy: Not Installed dateutil: Not Installed docker-py: Not Installed gitdb: 0.6.4 gitpython: 1.0.1 Jinja2: 2.11.1 libgit2: Not Installed M2Crypto: 0.35.2 Mako: Not Installed msgpack: 0.6.2 msgpack-pure: Not Installed mysql-python: Not Installed pycparser: Not Installed pycrypto: Not Installed pycryptodome: Not Installed pygit2: Not Installed Python: 3.6.8 (default, Nov 16 2020, 16:55:22) python-gnupg: Not Installed PyYAML: 3.13 PyZMQ: 17.0.0 smmap: 0.9.0 timelib: Not Installed Tornado: 4.5.3 ZMQ: 4.1.4
System Versions: dist: centos 7 Core locale: UTF-8 machine: x86_64 release: 3.10.0-1160.31.1.el7.x86_64 system: Linux version: CentOS Linux 7 Core
Additionally updated the master to 3003.1 and still having issue.
Issue is still persistent :(.
root@vagrant-test:~# salt-call --versions
Salt Version:
Salt: 3004
Dependency Versions:
cffi: Not Installed
cherrypy: Not Installed
dateutil: 2.8.1
docker-py: Not Installed
gitdb: 4.0.5
gitpython: 3.1.14
Jinja2: 2.11.3
libgit2: Not Installed
M2Crypto: Not Installed
Mako: Not Installed
msgpack: 1.0.0
msgpack-pure: Not Installed
mysql-python: Not Installed
pycparser: Not Installed
pycrypto: Not Installed
pycryptodome: 3.9.7
pygit2: Not Installed
Python: 3.9.2 (default, Feb 28 2021, 17:03:44)
python-gnupg: Not Installed
PyYAML: 5.3.1
PyZMQ: 20.0.0
smmap: 4.0.0
timelib: Not Installed
Tornado: 4.5.3
ZMQ: 4.3.4
System Versions:
dist: debian 11 bullseye
locale: utf-8
machine: x86_64
release: 5.10.0-9-amd64
system: Linux
version: Debian GNU/Linux 11 bullseye
I just spent over an hour on this issue. I really think the error message could be better here.
I often see the failure on freebsd 13 . I have collected a trace from salt-call trace.txt
[INFO ] Executing state file.managed for [/tmp/FileBot_4.9.4-portable-jdk8.tar.xz]
[ERROR ] (False, 'Unable to verify upstream hash of source file https://get.filebot.net/filebot/FileBot_4.9.4/FileBot_4.9.4-portable-jdk8.tar.xz, please set source_hash or set skip_verify to True')
[INFO ] Completed state [/tmp/FileBot_4.9.4-portable-jdk8.tar.xz] at time 22:54:12.842519 (duration_in_ms=7.744)
[DEBUG ] An exception occurred in this state: 'Changes' should be a dictionary.
Traceback (most recent call last):
File "/usr/local/lib/python3.8/site-packages/salt/utils/decorators/state.py", line 28, in _run_policies
data = pls(data)
File "/usr/local/lib/python3.8/site-packages/salt/utils/decorators/state.py", line 84, in content_check
raise SaltException(err_msg)
salt.exceptions.SaltException: 'Changes' should be a dictionary.
[DEBUG ] LazyLoaded archive.extracted
@sagetherage
I knew this looked familiar. Ran into it again!
should_be_a_dictionary_patch.txt
This patch fixed it for me.
if isinstance(ret["changes"], tuple):
ret["result"], ret["comment"] = ret["changes"]
...
return ret
ret["changes"] is clearly a tuple here, but it does not get changed before being returned, so the error message is correct; it's definitely not a dictionary.
By changing it like the below, which appears to be in line with the intention of the code (No changes because the source file does not exist), the bug is fixed.
if isinstance(ret["changes"], tuple):
ret["result"], ret["comment"] = ret["changes"]
ret["changes"] = {}
...
return ret
@dractyl I will try your patch next week. Thank you !
@garethgreenaway I ran into this again in CI when I had a source_hash value that wasn't a valid source hash type. e.g.: 0-8386d4b570fea53d4208d2133411e6d4
when it should have been 8386d4b570fea53d4208d2133411e6d4
. I'm running latest saltstack available to ubuntu 20.04. If you need more info or want to move to a new issue please lmk
Description of Issue
Hello!
In Salt
2019.2.2
(and likely any2019.2.x
version), when using thefile.managed
state and specifying asource
file that doesn't actually exist (e.g.source: salt://path/to/nonexistent/file.txt
),state.apply
will return a"'Changes' should be a dictionary"
error instead of returning the real error, i.e. that I'm trying to use a file that doesn't exist in SaltFS. This is a break from2018.3.x
which actually reports a usefulSource file not found
error.Setup
Steps to Reproduce Issue
Output when using Salt
2019.2.2
:When using Salt
2018.3.4
the output is much more useful:Versions Report