[BUG] salt.pillar.get_pillar broken since Salt 3003
#62477
Comments
|
More info on this: it seems like the object being sent to msgpack (see the end of the trace) File "/usr/local/lib/python3.9/site-packages/msgpack/__init__.py", line 38, in packb
return Packer(**kwargs).pack(o)is this: {'id': 'some-proxy', 'grains': <salt.loader.context.NamedLoaderContext object at 0x7f4fa2700f10>, 'saltenv': 'base', 'pillarenv': None, 'pillar_override': {}, 'extra_minion_data': {}, 'ver': '2', 'cmd': '_pillar', 'nonce': 'supersafe'}This gets sent to |
|
It turns out that the error is caused by the fact that the Grains are passed in as the ret = salt.pillar.get_pillar(
__opts__, __grains__.value(), __opts__["id"], __opts__.get("saltenv"), ext=ext
).compile_pillar()I am happy to close this one out, but I'd like to see if the core team would find value in checking the data type of the |
|
Also happens when passing a simple pillar on the command line (using 3004.2): Looks like a pretty serious bug to me - no workaround available to command line users |
|
@mirceaulinic Curious, the versions-report states Salt 3004.2, but the python version used is Python 3.9.13 but the default OS version for Debian 10 is Python 3.7.3, and given this is a (classic) package which depends on the OS to supply dependencies (not Onedir - only available with Salt 3005.1), typically they need the default OS python3 version to operate correctly ? |
|
I wonder if this will fix the issue #64043 |
|
Can confirm with The 3002.9 minion on Debian 10 works fine, but 3005.1 minion on Debian 11, has issues, from RHEL 7 salt-master 3002.9 |
|
Upgrade to salt-master with 3005.1 and issue still exists |
|
The problem is here trying to do a dict of the obj throws an exception, in salt/payload.py |
|
Simplifying the test which produces the error |
|
Moving this to 3006.1, to allow for more time to research NamedLoaderContext issue not containing a loader which results in None. |
|
It appears to be a deep copy issue in salt/utils/asynchronous.py the _wrap starts a thread with function _target, This may be an issue with other args passed to the thread which also require a deepcopy too. The following is the debug output with testing of grains. |
|
After chatting with @dwoz , want to limit the NamedLoaderContext use with dunder grains, pillars, etc. within the execution modules where it was created, and hence use value() for anywhere it goes beyond the execution modules, for example: accessing / updating / gathering pillar information. |
|
Closing since PR #64055 merged |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
A clear and concise description of what the bug is.
I have a custom execution module were I need to compile Pillars given a custom git branch. This is done by invoking
salt.pillar.get_pillar. I had no troubles running this across many Salt versions (including 3002.9 currently), but upgrading to anything above 3003 (including 3005rc2), it errors out.The reasoning why we're needing this call is that we have a gitfs backend, and need on-demand Pillar data compiled for whatever branch the user requires.
Trace:
Setup
A Salt Master and a Proxy Minion (any flavour) running Salt 3003+, and a custom execution module with these functions:
Master configuration:
This code has been running in production, and currently under 3002.9 perfectly fine.
Steps to Reproduce the behavior
salt <tgt> custom_module.get_pillarExpected behavior
I'd expect to get the pillar not the trace.
Versions Report
salt --versions-report
(Provided by running salt --versions-report. Please also mention any differences in master/minion versions.)Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: