-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
[TECH DEBT] Salt fails to load top.sls on Python3.13rc2 #66898
Comments
Take care that as if is related to cython it's independent from python3.13. I have the same bug (and same fix working) for python 3.12.6/cython 3.0.11 |
Indeed Python 3.12.6 is affected too, and so is Fedora 40 and 39. |
Python 3.13 fixed handling relative paths in urllib.parse module. Specifically, relative file URL is now constructed as file:path instead of converting it to absolute file:///path. This breaks salt.utils.url.create which expects file:/// specifically. The mismatch results in for example changing salt://top.sls into salt://.sls and thus not finding the top file. Fix this by handling both prefixes. Relevant python change: python/cpython#85110 Fixes: saltstack#66898
Python 3.13 fixed handling relative paths in urllib.parse module. Specifically, relative file URL is now constructed as file:path instead of converting it to absolute file:///path. This breaks salt.utils.url.create which expects file:/// specifically. The mismatch results in for example changing salt://top.sls into salt://.sls and thus not finding the top file. Fix this by handling both prefixes. Relevant python change: python/cpython#85110 Fixes: saltstack#66898
Python 3.13 fixed handling relative paths in urllib.parse module. Specifically, relative file URL is now constructed as file:path instead of converting it to absolute file:///path. This breaks salt.utils.url.create which expects file:/// specifically. The mismatch results in for example changing salt://top.sls into salt://.sls and thus not finding the top file. Fix this by handling both prefixes. Relevant python change: python/cpython#85110 Fixes: saltstack#66898
This is the only bug I have seen so far running on python 3.12. |
This seems to be the effective point of code change for the upstream issue. |
Python 3.13 fixed handling relative paths in urllib.parse module. Specifically, relative file URL is now constructed as file:path instead of converting it to absolute file:///path. This breaks salt.utils.url.create which expects file:/// specifically. The mismatch results in for example changing salt://top.sls into salt://.sls and thus not finding the top file. Fix this by handling both prefixes. Relevant python change: python/cpython#85110 Fixes: saltstack#66898
Python 3.13 fixed handling relative paths in urllib.parse module. Specifically, relative file URL is now constructed as file:path instead of converting it to absolute file:///path. This breaks salt.utils.url.create which expects file:/// specifically. The mismatch results in for example changing salt://top.sls into salt://.sls and thus not finding the top file. Fix this by handling both prefixes. Relevant python change: python/cpython#85110 Fixes: saltstack#66898
Python 3.13 fixed handling relative paths in urllib.parse module. Specifically, relative file URL is now constructed as file:path instead of converting it to absolute file:///path. This breaks salt.utils.url.create which expects file:/// specifically. The mismatch results in for example changing salt://top.sls into salt://.sls and thus not finding the top file. Fix this by handling both prefixes. Relevant python change: python/cpython#85110 Fixes: saltstack#66898
Python 3.13 fixed handling relative paths in urllib.parse module. Specifically, relative file URL is now constructed as file:path instead of converting it to absolute file:///path. This breaks salt.utils.url.create which expects file:/// specifically. The mismatch results in for example changing salt://top.sls into salt://.sls and thus not finding the top file. Fix this by handling both prefixes. Relevant python change: python/cpython#85110 Fixes: saltstack#66898
…on 3.12 Issue: saltstack#66898 PR with fix: https://github.com/saltstack/salt/pull/66899/files Signed-off-by: Cristian Hotea <[email protected]>
@marmarek thanks for your report and candidate pull request #66899, it proved to be of great help already at #66588 (comment) 🙏 What I don't understand is the label "tech debt". It seems like a plain bug (and a big one that made salt-ssh completely unusable to me without the fix), and "tech debt" may send the wrong signal. Could it be dropped from the title? What was the idea? |
(+1 ...maybe) # cat /srv/salt/k/init.sls
always-passes-with-any-kwarg k:
test.nop:
- name: foo
- something: {{ tplfile }}
- foo: bar A show_sls then gives:
Every preceeding 'u' in the state specification is ignored, and instead state 'k' is/would be applied. Regarding "Tech Debt"-label; it has no describing text so I can only guess from it's name the bug is related to salt-stack falling behind the newest and greatest technology. I don't think it says or send any signal regarding it's severity, it's just a clue to getting it fixed. |
Description of the tech debt to be addressed, include links and screenshots
A recent change in Python 3.13 causes salt to fails on loading top.sls. With debugging enabled, I see now:
This seems to be directly caused by the change in Python: python/cpython#85110
Old behavior:
New behavior:
Technically, I think the latter might be more correct. But it still breaks salt's expectations. Specifically here:
salt/salt/utils/url.py
Lines 49 to 50 in 246d066
With
file:top.sls
, looking for length offile:///
is wrong now.Versions Report
(Provided by running
salt --versions-report
. Please also mention any differences in master/minion versions.)The same issue applies to Fedora 41 (in beta now). And while I tested using Salt 3006.9, the relevant code is the same in master.
The text was updated successfully, but these errors were encountered: