Skip to content
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

[BUG] salt-ssh yumpkg broken on 3006.9 for remote servers with Python < 3.8 #67091

Open
7 of 9 tasks
lukasraska opened this issue Dec 9, 2024 · 2 comments
Open
7 of 9 tasks
Labels
Bug broken, incorrect, or confusing behavior needs-triage

Comments

@lukasraska
Copy link
Contributor

Description

Because 378b106 introduced Python 3.8+ syntax (:= - assignment expression), any interaction with such syntax on Python < 3.8 raises SyntaxError. This is especially unfortunate, since the only place where this is used is yumpkg, which in case of RHEL 8 (and derivates) fails because the system uses Python 3.6 by default.

This is also regression between 3006.8 and 3006.9:

It can be easily reproduced on Salt-SSH, since it bundles all the available modules, which then fail (either directly using pkg.<something> or in states with errors such as pkgrepo: __virtual__ returned False

Setup

Any setup where server running salt-ssh is 3006.9 and destination server has Python < 3.8 and is using yum/dnf (e..g Rocky Linux 8 / Red Hat Enteprise Linux 8 / Alma Linux 8 / etc.)

Please be as specific as possible and give set-up details.

  • on-prem machine
  • VM (Virtualbox, KVM, etc. please specify)
  • VM running on a cloud service, please be explicit and add details
  • container (Kubernetes, Docker, containerd, etc. please specify)
  • or a combination, please be explicit
  • jails if it is FreeBSD
  • classic packaging
  • onedir packaging
  • used bootstrap to install

Steps to Reproduce the behavior

Configure salt-ssh to remote machine with older Python, observe fail with any pkg interaction:

$ salt-ssh tst-rocky8-01 test.ping
tst-rocky8-01:
    True
$ salt-ssh tst-rocky8-01 pkg.info salt
tst-rocky8-01:
    ----------
    retcode:
        255
    stderr:
        Connection to <ip> closed.
    stdout:

In logs (e.g. by monkeypatching with obviously not resolved suggestion in #16417), you can see following error

2024-12-09 16:27:00,881 [salt.loader.lazy :810 ][ERROR   ][3484956] Failed to import module yumpkg, this is due most likely to a syntax error:
Traceback (most recent call last):
  File "/var/tmp/.c25d60/pyall/salt/loader/lazy.py", line 785, in _load_module
    mod = self.run(spec.loader.load_module)
  File "/var/tmp/.c25d60/pyall/salt/loader/lazy.py", line 1245, in run
    return self._last_context.run(self._run_as, _func_or_method, *args, **kwargs)
  File "/var/tmp/.c25d60/py3/contextvars/__init__.py", line 38, in run
    return callable(*args, **kwargs)
  File "/var/tmp/.c25d60/pyall/salt/loader/lazy.py", line 1260, in _run_as
    ret = _func_or_method(*args, **kwargs)
  File "<frozen importlib._bootstrap_external>", line 399, in _check_name_wrapper
  File "<frozen importlib._bootstrap_external>", line 823, in load_module
  File "<frozen importlib._bootstrap_external>", line 682, in load_module
  File "<frozen importlib._bootstrap>", line 265, in _load_module_shim
  File "<frozen importlib._bootstrap>", line 684, in _load
  File "<frozen importlib._bootstrap>", line 665, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 674, in exec_module
  File "<frozen importlib._bootstrap_external>", line 781, in get_code
  File "<frozen importlib._bootstrap_external>", line 741, in source_to_code
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
  File "/var/tmp/.c25d60/pyall/salt/modules/yumpkg.py", line 1427
    if (version := kwargs.get("version")) is not None:
                ^
SyntaxError: invalid syntax

Expected behavior

yumpkg works using salt-ssh to RHEL 8 and derivates since those are expected to be in support at least to 2029 (https://access.redhat.com/support/policy/updates/errata )

Screenshots

n/a

Versions Report

salt --versions-report
$ salt-call --versions-report
Salt Version:
          Salt: 3006.9
 
Python Version:
        Python: 3.10.15 (main, Oct 28 2024, 10:47:38) [GCC 11.2.0]
 
Dependency Versions:
          cffi: 1.14.6
      cherrypy: 18.6.1
  cryptography: 42.0.5
      dateutil: 2.8.1
     docker-py: Not Installed
         gitdb: 4.0.11
     gitpython: 3.1.43
        Jinja2: 3.1.4
       libgit2: Not Installed
  looseversion: 1.0.2
      M2Crypto: Not Installed
          Mako: Not Installed
       msgpack: 1.0.2
  msgpack-pure: Not Installed
  mysql-python: Not Installed
     packaging: 22.0
     pycparser: 2.21
      pycrypto: Not Installed
  pycryptodome: 3.19.1
        pygit2: Not Installed
  python-gnupg: 0.4.8
        PyYAML: 6.0.1
         PyZMQ: 23.2.0
        relenv: 0.18.0
         smmap: 5.0.1
       timelib: 0.2.4
       Tornado: 4.5.3
           ZMQ: 4.3.4
 
System Versions:
          dist: rocky 9.4 Blue Onyx
        locale: utf-8
       machine: x86_64
       release: 5.14.0-427.22.1.el9_4.x86_64
        system: Linux
       version: Rocky Linux 9.4 Blue Onyx

Remote server:

[root@tst-rocky8-01 ~]# python3 --version
Python 3.6.8
[root@tst-rocky8-01 ~]# cat /etc/redhat-release 
Rocky Linux release 8.9 (Green Obsidian)

Additional context

n/a

@lukasraska lukasraska added Bug broken, incorrect, or confusing behavior needs-triage labels Dec 9, 2024
@stratusjerry
Copy link
Contributor

Seeing the same issue, salt-ssh failing with any pkg module commands on RHEL 8. Bumping log level to trace doesn't given any better failure but monkeypatching yumpkg.py to 3006.8 version and running via salt-call fixes the issue. @twangboy can this be reverted in 3006 branch?

@Steve973
Copy link

It might also be helpful to have the ability (i.e., config parameter) to tell the remote system which version of python it should be using. Wouldn't that be a decent and effective approach? I tried to force it to use other versions of python, and although I'm not the most experienced user of saltstack, I was unable to get it to use newer versions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug broken, incorrect, or confusing behavior needs-triage
Projects
None yet
Development

No branches or pull requests

3 participants