[BUG] gitfs is suddenly a hassle with onedir package

hkbakke commented 2 years ago

Description I upgraded to the 3005 onedir package on my salt master. The salt-master is configured to use gitfs and git_pillar via pygit2. I expected this critical salt master functionality to "just work" but I actually had to install the pygit2 module using salt pip install pygit2 --no-deps. I used no-deps as pip drags in a newer version of cffi conflicting with the included onedir version if I don't.

However, pygit2 fails during startup of the salt master because ssl setup fails. I only use ssh git urls, but being able to configure ca certificates location seems to be a requirement for the pygit2 module.

During startup the salt master fails with:

2022-09-08 08:34:15,880 [salt.utils.gitfs :148 ][ERROR   ][1607008] Failed to import pygit2
Traceback (most recent call last):
  File "salt/utils/gitfs.py", line 108, in <module>
    import pygit2
  File "/opt/saltstack/salt/pypath/lib/python3.9/site-packages/pygit2/__init__.py", line 230, in <module>
    settings = Settings()
  File "/opt/saltstack/salt/pypath/lib/python3.9/site-packages/pygit2/settings.py", line 55, in __init__
    self._initialize_tls_certificate_locations()
  File "/opt/saltstack/salt/pypath/lib/python3.9/site-packages/pygit2/settings.py", line 61, in _initialize_tls_certificate_l
ocations
    self.set_ssl_cert_locations(
  File "/opt/saltstack/salt/pypath/lib/python3.9/site-packages/pygit2/settings.py", line 191, in set_ssl_cert_locations
    option(_pygit2.GIT_OPT_SET_SSL_CERT_LOCATIONS, cert_file, cert_dir)
_pygit2.GitError: OpenSSL error: failed to load certificates: error:00000000:lib(0):func(0):reason(0)
2022-09-08 08:34:16,151 [salt.master      :2475][INFO    ][1602761] User root Published command test.version with jid 2022090
8063416149168

I found that I could solve this by setting the SSL_CERT_FILE environment variable to the os default location which is /etc/ssl/certs/ca-certificates.crt in my case. I could not find a way to configure this in the configuration so I have to do it the cumbersome way by making an systemd override file /etc/systemd/system/salt-master.service.d/override.conf containing:

[Service]
Environment=SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt

This fixes the master startup error, and minions can connect and execute states afterwards. However, for some reason if I execute salt-call for the local master minion I still get the pygit2 ssl cert error printed to the screen, while the states executes seemingly properly. To fix this I have to ensure the SSL_CERT_FILE env var is set for manual salt-call invokations of the minion on the master itself e.g:

sudo SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt salt-call state.apply

This is obviously cumbersome, so I would like a way for this to be configured once only, prefererrably within saltstack, not using linux workarounds like systemd overrides and shell aliases.

Also: pygit2 version is not reported when printing the version report even though it is available within the salt onedir env.

Steps to Reproduce the behavior

Install onedir package
Install missing pygit2 dependency in salt onedir env: salt pip install pygit2 --no-deps
Install missing libgit2 dependency in OS (apt install libgit2-1.1 in Debian 11)
Configure gitfs_provider as pygit2 with valid gitfs configuration and repo
Try to start salt master

Expected behavior

Minimum: document how to use gitfs properly with onedir
Expected: pygit2 should be included in onedir package and SSL_CERT_DIR/SSL_CERT_FILE env params should be configurable globally in the salt master config or automatically set to a sane default.

Versions Report

Salt Version:
          Salt: 3005

Dependency Versions:
          cffi: 1.14.6
      cherrypy: unknown
      dateutil: 2.8.1
     docker-py: Not Installed
         gitdb: Not Installed
     gitpython: Not Installed
        Jinja2: 3.1.0
       libgit2: Not Installed
      M2Crypto: Not Installed
          Mako: Not Installed
       msgpack: 1.0.2
  msgpack-pure: Not Installed
  mysql-python: Not Installed
     pycparser: 2.21
      pycrypto: Not Installed
  pycryptodome: 3.9.8
        pygit2: Not Installed
        Python: 3.9.13 (main, Aug 23 2022, 18:31:09)
  python-gnupg: 0.4.8
        PyYAML: 5.4.1
         PyZMQ: 23.2.0
         smmap: Not Installed
       timelib: 0.2.4
       Tornado: 4.5.3
           ZMQ: 4.3.4

System Versions:
          dist: debian 11 bullseye
        locale: utf-8
       machine: x86_64
       release: 5.10.0-17-amd64
        system: Linux
       version: Debian GNU/Linux 11 bullseye

# sudo salt pip freeze
pygit2==1.10.1

welcome[bot] commented 2 years ago

Hi there! Welcome to the Salt Community! Thank you for making your first contribution. We have a lengthy process for issues and PRs. Someone from the Core Team will follow up as soon as possible. In the meantime, here’s some information that may help as you continue your Salt journey. Please be sure to review our Code of Conduct. Also, check out some of our community resources including:

There are lots of ways to get involved in our community. Every month, there are around a dozen opportunities to meet with other contributors and the Salt Core team and collaborate in real time. The best way to keep track is by subscribing to the Salt Community Events Calendar. If you have additional questions, email us at saltproject@vmware.com. We’re glad you’ve joined our community and look forward to doing awesome things with you!

garethgreenaway commented 2 years ago

Confirmed this is an issue, as a workaround when installing using salt pip if you set the SSL_CERT_DIR variable when installing then it works as expected.

garethgreenaway commented 2 years ago

I did a bit more digging and found this:

Using system version of Python

Python 3.9.2 (default, Feb 28 2021, 17:03:44) 
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ssl
>>> ssl.get_default_verify_paths
<function get_default_verify_paths at 0x7f885d201940>
>>> ssl.get_default_verify_paths()
DefaultVerifyPaths(cafile=None, capath='/usr/lib/ssl/certs', openssl_cafile_env='SSL_CERT_FILE', openssl_cafile='/usr/lib/ssl/cert.pem', openssl_capath_env='SSL_CERT_DIR', openssl_capath='/usr/lib/ssl/certs')
>>> quit
Use quit() or Ctrl-D (i.e. EOF) to exit
>>>

Using Salt onedir version of Python

root@host-150:~/pygit2-1.4.0# salt shell
Python 3.9.13 (main, Sep  6 2022, 21:38:11) 
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> import ssl
>>> ssl.get_default_verify_paths()
DefaultVerifyPaths(cafile=None, capath=None, openssl_cafile_env='SSL_CERT_FILE', openssl_cafile='/usr/local/openssl11/cert.pem', openssl_capath_env='SSL_CERT_DIR', openssl_capath='/usr/local/openssl11/certs')

When installing pygit2 the above function is used to determine where the SSL certs are located, since we're building the onedir packages on a different system the locations are different than Debian. In the returned data the two environment variables that can be used to override the values are visible. This seems like the solution for installing pygit2 using onedir packages and we should document this.

garethgreenaway commented 2 years ago

Posted too soon, I had to have the environmental variable SSL_CERT_DIR set to the correct path when starting the Salt master or when running the shell command in the onedir environment when loading pygit2 to ensure that I didn't see an error.

I'm not sure building the onedir packages with pygit2 included would solve the issue as the path to the SSL certs is still going to be different.

waynew commented 2 years ago

I wonder if we can adjust the way our onedir is built to ensure that the paths are correct :thinking:

hkbakke commented 2 years ago

Posted too soon, I had to have the environmental variable SSL_CERT_DIR set to the correct path when starting the Salt master or when running the shell command in the onedir environment when loading pygit2 to ensure that I didn't see an error.

I'm not sure building the onedir packages with pygit2 included would solve the issue as the path to the SSL certs is still going to be different.

The "include pygit2" part is not really about the SSL cert path working out of the box, but that I, perhaps naively, expect the onedir package to contain the needed dependencies to use what I personally consider core functionality for the salt master, although I know many probably run without git backing in simpler deployments. I personally can live with configuring the cert path in a salt config file or some other documented location. There is also the part that pygit2 installed after the fact by salt pip causes pip to produce warnings about cffi versions conflicting confusing the user, something that would not be an issue if it was part of the onedir env as the cffi version within the onedir env is within the requirements of pygit2.

garethgreenaway commented 2 years ago

As mentioned before including pygit2 in the onedir package wouldn't have completely solved the issue in this particular case. Since we build the onedir portion on the packages, eg. Python and all the requirements, on a CentOS 7 host (to ensure the lowest common denominator for libraries such as GLIBC) the location for the SSL certs will be different than where it ultimately runs.

To ensure that pygit2 is able to load and the traceback doesn't show up, is to ensure that the SSL_CERT_DIR environment variable is always available, the fix that I've submitted and will be available in the upcoming 3005.1 release is to include some shell code in the helper scripts for running salt commands, eg. salt, salt-call, salt-key, salt-master, and salt-minion, that set the SSL_CERT_DIR environmental variable (if it's not already set) with the output from openssl version -d, which is the correct location for the local system where the Salt command is running.

https://gitlab.com/saltstack/open/salt-pkg/-/merge_requests/202

garethgreenaway commented 2 years ago

Fixed by https://gitlab.com/saltstack/open/salt-pkg/-/merge_requests/202

transistortim commented 1 year ago

The issue still exists with salt-ssh in 3005.1. Is there a particular reason why the fix was not applied to salt-ssh? If I manually extend the salt-ssh script with what was added to the other commands, the errors are gone.

Output without applying the fix (same as above)

```shell % salt-ssh minion test.ping [ERROR ] Failed to import pygit2 Traceback (most recent call last): File "salt/utils/gitfs.py", line 108, in import pygit2 File "/opt/saltstack/salt/pypath/lib/python3.9/site-packages/pygit2/__init__.py", line 230, in settings = Settings() File "/opt/saltstack/salt/pypath/lib/python3.9/site-packages/pygit2/settings.py", line 55, in __init__ self._initialize_tls_certificate_locations() File "/opt/saltstack/salt/pypath/lib/python3.9/site-packages/pygit2/settings.py", line 61, in _initialize_tls_certificate_locations self.set_ssl_cert_locations( File "/opt/saltstack/salt/pypath/lib/python3.9/site-packages/pygit2/settings.py", line 191, in set_ssl_cert_locations option(_pygit2.GIT_OPT_SET_SSL_CERT_LOCATIONS, cert_file, cert_dir) _pygit2.GitError: OpenSSL error: failed to load certificates: error:00000000:lib(0):func(0):reason(0) [CRITICAL] No suitable gitfs provider module is installed. [CRITICAL] No suitable gitfs provider module is installed. minion: ```

Fixed salt-ssh (lines copied from https://gitlab.com/saltstack/open/salt-pkg/-/blob/11547966959ca2e522862f52268ff6fa1e53f592/pkgs/debian/debian/one-dir-bins/salt):

% cat /usr/bin/salt-ssh
#!/bin/bash
if [[ -z "${SSL_CERT_DIR}" ]] && command -v openssl &> /dev/null; then
  _DIR=$(openssl version -d)
  export SSL_CERT_DIR=${_DIR:13:-1}"/certs"
  export SSL_CERT_FILE=${_DIR:13:-1}"/cert.pem"
fi
exec /opt/saltstack/salt/run/run ssh "${@:1}"

Output with fixed salt-ssh:

% salt-ssh minion test.ping
minion:
    <minion summary>

Salt version report (onedir)

```yaml % salt-ssh --versions-report Salt Version: Salt: 3005.1 Dependency Versions: cffi: 1.14.6 cherrypy: 18.6.1 dateutil: 2.8.1 docker-py: Not Installed gitdb: Not Installed gitpython: Not Installed Jinja2: 3.1.0 libgit2: Not Installed M2Crypto: Not Installed Mako: Not Installed msgpack: 1.0.2 msgpack-pure: Not Installed mysql-python: Not Installed pycparser: 2.21 pycrypto: Not Installed pycryptodome: 3.9.8 pygit2: Not Installed Python: 3.9.16 (main, Dec 14 2022, 15:47:34) python-gnupg: 0.4.8 PyYAML: 5.4.1 PyZMQ: 23.2.0 smmap: Not Installed timelib: 0.2.4 Tornado: 4.5.3 ZMQ: 4.3.4 System Versions: dist: debian n/a bookworm locale: utf-8 machine: x86_64 release: 6.0.0-6-amd64 system: Linux version: Debian GNU/Linux n/a bookworm ```

Despite the version report, pygit2 is installed (as already mentioned above):

% salt-pip freeze
pygit2==1.6.1

rosscdh commented 1 year ago

still happens

salt-run fileserver.update backend=git -l debug

[INFO    ] Runner completed: 20230303032450303838
[DEBUG   ] Runner return: Exception occurred in runner fileserver.update: Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/salt/client/mixins.py", line 386, in low
    data["return"] = func(*args, **kwargs)
  File "/usr/local/lib/python3.7/site-packages/salt/loader/lazy.py", line 149, in __call__
    return self.loader.run(run_func, *args, **kwargs)
.... snip ....
  File "/usr/local/lib/python3.7/site-packages/salt/utils/gitfs.py", line 216, in failhard
    raise FileserverConfigError("Failed to load {}".format(role))
salt.exceptions.FileserverConfigError: Failed to load gitfs

Salt Version:
          Salt: 3005.1

Dependency Versions:
          cffi: 1.14.6
      cherrypy: unknown
      dateutil: 2.8.1
     docker-py: Not Installed
         gitdb: 4.0.10
     gitpython: 3.1.31
        Jinja2: 3.1.0
       libgit2: 1.1.0
      M2Crypto: Not Installed
          Mako: Not Installed
       msgpack: 1.0.2
  msgpack-pure: Not Installed
  mysql-python: Not Installed
     pycparser: 2.17
      pycrypto: Not Installed
  pycryptodome: 3.9.8
        pygit2: 1.6.1
        Python: 3.7.13 (default, Apr 20 2022, 03:16:50)
  python-gnupg: 0.4.8
        PyYAML: 5.4.1
         PyZMQ: 18.0.1
         smmap: 5.0.0
       timelib: 0.2.4
       Tornado: 4.5.3
           ZMQ: 4.3.1

System Versions:
          dist: alpine 3.14.6
        locale: UTF-8
       machine: x86_64
       release: 5.15.0-60-generic
        system: Linux
       version: Alpine Linux 3.14.6

echo $SSL_CERT_DIR
/etc/ssl/certs

OrangeDog commented 1 year ago

3006-RC is now available. Is there any improvement there?

peterbaumert commented 1 year ago

3006-RC is now available. Is there any improvement there?

I still have the error with 3006.0 and the netbox external pillar :(

MTecknology commented 1 year ago

Why was this closed? The error appears to remain unresolved, and the broader issue persists. Why are we compelled to embrace such a broken and non-standard installation option? Could the onedir format not have undergone some reasonable level of testing before being imposed on users?

Darkentik commented 9 months ago

I am still having this issues and cannot understand why this was closed. We are using debian bookworm with 3005 because the 3006 with pygit2 has the same problems and it is pain.

max-arnold commented 9 months ago

Gitpython installed via salt-pip works like a charm on 3006.5 with the following config:

gitfs_provider: gitpython
gitfs_update_interval: 120
gitfs_global_lock: false
file_roots: {}

fileserver_backend:
  - roots
  - gitfs

gitfs_remotes:
  - https://USER:DEPLOY_TOKEN@gitlab.com/ORG/REPO.git:
    - base: main
    - root: states

top_file_merging_strategy: same

# Git Pillar
pillar_roots: {}

git_pillar_provider: gitpython
git_pillar_base: main
git_pillar_branch: main
pillarenv_from_saltenv: true
ext_pillar_first: true
git_pillar_update_interval: 120
git_pillar_global_lock: false

ext_pillar:
  - git:
    - main https://USER:DEPLOY_TOKEN@gitlab.com/ORG/REPO.git:
      - root: pillar

main (referenced 4 times in the above snippet) is the primary git branch that is mapped to the base saltenv, state files are kept in the states repo folder, pillars are in the pillar folder

ipaqmaster commented 4 months ago

Also experiencing this problem with salt not liking a newer version of pygit2 but breaking in minion connectivity (TCP Publish Client encountered an exception while connecting to /var/run/salt/master/master_event_pub.ipc: StreamClosedError('Stream is closed') when an older version is used.

Onedir complains about pygit2 not being present and salt-pip refuses to install it for any number of errors. The above does not work either after using salt-pip to install gitpython.

It's hopeless. I've resorted to pointing it at the filesystem and using an external solution to keep the git repository it points to up to date.

MTecknology commented 4 months ago

FWIW, it seems to work best to just manage salt as a python virtual environment: https://github.com/MTecknology/teckhost/blob/master/bootstrap#L147 (/opt/salt/bin/salt-call)

jamest-pin commented 3 months ago

I'm getting this after upgrading to onedir

salt-pip install pygit2
Requirement already satisfied: pygit2 in /opt/saltstack/salt/extras-3.10 (1.15.1)
Requirement already satisfied: cffi>=1.16.0 in /opt/saltstack/salt/lib/python3.10/site-packages (from pygit2) (1.16.0)
Requirement already satisfied: pycparser in /opt/saltstack/salt/lib/python3.10/site-packages (from cffi>=1.16.0->pygit2) (2.21)
ERROR: Exception:
Traceback (most recent call last):
  File "/opt/saltstack/salt/lib/python3.10/site-packages/pip/_internal/cli/base_command.py", line 179, in exc_logging_wrapper
    status = run_func(*args)
  File "/opt/saltstack/salt/lib/python3.10/site-packages/relenv/runtime.py", line 638, in wrapper
    return func(self, options, args)
  File "/opt/saltstack/salt/lib/python3.10/site-packages/pip/_internal/cli/req_command.py", line 67, in wrapper
    return func(self, options, args)
  File "/opt/saltstack/salt/lib/python3.10/site-packages/pip/_internal/commands/install.py", line 466, in run
    lib_locations = get_lib_location_guesses(
  File "/opt/saltstack/salt/lib/python3.10/site-packages/pip/_internal/commands/install.py", line 644, in get_lib_location_guesses
    scheme = get_scheme(
  File "/opt/saltstack/salt/lib/python3.10/site-packages/relenv/runtime.py", line 673, in wrapper
    scheme.platlib = TARGET.PATH
  File "<string>", line 4, in __setattr__
dataclasses.FrozenInstanceError: cannot assign to field 'platlib'

This happens on pretty much any package install. salt-pip appears to be broken

jamest-pin commented 3 months ago

For anyone else struggling with this, this seemed to work for me (referring to the salt pip3 binary directly) That allowed me to install 1.14.1 since 1.15.0 doesn't work.

salt@salt:/srv$ /opt/saltstack/salt/bin/pip3 list | grep pygit
salt@salt:/srv$ /opt/saltstack/salt/bin/pip3 install pygit2==1.14.1
Collecting pygit2==1.14.1
  Using cached pygit2-1.14.1-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (3.4 kB)
Collecting cffi>=1.16.0 (from pygit2==1.14.1)
  Using cached cffi-1.16.0-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (1.5 kB)
Requirement already satisfied: pycparser in /opt/saltstack/salt/lib/python3.10/site-packages (from cffi>=1.16.0->pygit2==1.14.1) (2.21)
Using cached pygit2-1.14.1-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (5.1 MB)
Using cached cffi-1.16.0-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (443 kB)
Installing collected packages: cffi, pygit2
  Do not adjust rpath of /opt/saltstack/salt/lib/python3.10/site-packages/_cffi_backend.cpython-310-x86_64-linux-gnu.so
  Do not adjust rpath of /opt/saltstack/salt/lib/python3.10/site-packages/pygit2.libs/libcrypto-e196e492.so.3
  WARNING: Unable to find library libssl-107481d2.so.3 linked from /opt/saltstack/salt/lib/python3.10/site-packages/pygit2.libs/libgit2-6834971d.so.1.7.2
  WARNING: Unable to find library libcrypto-e196e492.so.3 linked from /opt/saltstack/salt/lib/python3.10/site-packages/pygit2.libs/libgit2-6834971d.so.1.7.2
  WARNING: Unable to find library libpcre-9513aab5.so.1.2.0 linked from /opt/saltstack/salt/lib/python3.10/site-packages/pygit2.libs/libgit2-6834971d.so.1.7.2
  WARNING: Unable to find library libssh2-c5cb4cb9.so.1.0.1 linked from /opt/saltstack/salt/lib/python3.10/site-packages/pygit2.libs/libgit2-6834971d.so.1.7.2
  Do not adjust rpath of /opt/saltstack/salt/lib/python3.10/site-packages/pygit2.libs/libgit2-6834971d.so.1.7.2
  Do not adjust rpath of /opt/saltstack/salt/lib/python3.10/site-packages/pygit2.libs/libpcre-9513aab5.so.1.2.0
  WARNING: Unable to find library libssl-107481d2.so.3 linked from /opt/saltstack/salt/lib/python3.10/site-packages/pygit2.libs/libssh2-c5cb4cb9.so.1.0.1
  WARNING: Unable to find library libcrypto-e196e492.so.3 linked from /opt/saltstack/salt/lib/python3.10/site-packages/pygit2.libs/libssh2-c5cb4cb9.so.1.0.1
  Do not adjust rpath of /opt/saltstack/salt/lib/python3.10/site-packages/pygit2.libs/libssh2-c5cb4cb9.so.1.0.1
  WARNING: Unable to find library libcrypto-e196e492.so.3 linked from /opt/saltstack/salt/lib/python3.10/site-packages/pygit2.libs/libssl-107481d2.so.3
  Do not adjust rpath of /opt/saltstack/salt/lib/python3.10/site-packages/pygit2.libs/libssl-107481d2.so.3
  File already within root directory: /opt/saltstack/salt/lib/python3.10/site-packages/pygit2/../pygit2.libs/libgit2-6834971d.so.1.7.2
  File already within root directory: /opt/saltstack/salt/lib/python3.10/site-packages/pygit2/../pygit2.libs/libssl-107481d2.so.3
  File already within root directory: /opt/saltstack/salt/lib/python3.10/site-packages/pygit2/../pygit2.libs/libcrypto-e196e492.so.3
  File already within root directory: /opt/saltstack/salt/lib/python3.10/site-packages/pygit2/../pygit2.libs/libpcre-9513aab5.so.1.2.0
  File already within root directory: /opt/saltstack/salt/lib/python3.10/site-packages/pygit2/../pygit2.libs/libssh2-c5cb4cb9.so.1.0.1
  Adjust rpath of /opt/saltstack/salt/lib/python3.10/site-packages/pygit2/_libgit2.abi3.so to $ORIGIN/../../..
  Set RPATH=$ORIGIN/../../..:$ORIGIN/../pygit2.libs /opt/saltstack/salt/lib/python3.10/site-packages/pygit2/_libgit2.abi3.so
  File already within root directory: /opt/saltstack/salt/lib/python3.10/site-packages/pygit2/../pygit2.libs/libgit2-6834971d.so.1.7.2
  File already within root directory: /opt/saltstack/salt/lib/python3.10/site-packages/pygit2/../pygit2.libs/libssl-107481d2.so.3
  File already within root directory: /opt/saltstack/salt/lib/python3.10/site-packages/pygit2/../pygit2.libs/libcrypto-e196e492.so.3
  File already within root directory: /opt/saltstack/salt/lib/python3.10/site-packages/pygit2/../pygit2.libs/libpcre-9513aab5.so.1.2.0
  File already within root directory: /opt/saltstack/salt/lib/python3.10/site-packages/pygit2/../pygit2.libs/libssh2-c5cb4cb9.so.1.0.1
  Adjust rpath of /opt/saltstack/salt/lib/python3.10/site-packages/pygit2/_pygit2.cpython-310-x86_64-linux-gnu.so to $ORIGIN/../../..
  Set RPATH=$ORIGIN/../../..:$ORIGIN/../pygit2.libs /opt/saltstack/salt/lib/python3.10/site-packages/pygit2/_pygit2.cpython-310-x86_64-linux-gnu.so
Successfully installed cffi-1.16.0 pygit2-1.14.1
salt@salt:/srv$ salt-pip list | grep pygit
pygit2             1.14.1

I was then able to run the datadog sls from the gitfs backend

salt@salt:/srv$ salt-pip list | grep pygit
pygit2             1.14.1
salt@salt:/srv$ salt 'salt' state.apply datadog
salt:
    Data failed to compile:
----------
    No matching sls found for 'datadog' in env 'base'
ERROR: Minions returned with non-zero exit code
salt@salt:/srv$ exit
exit
james_t@salt:~$ sudo systemctl restart salt-master
james_t@salt:~$ sudo su salt
salt@salt:/home/james_t$ salt 'salt' state.apply datadog
salt:
----------
          ID: datadog-apt-https
    Function: pkg.installed
        Name: apt-transport-https
      Result: True
     Comment: All specified packages are already installed
     Started: 07:29:36.870046
[truncated]

dmurphy18 commented 3 months ago

@jamest-pin Please open a new issue for the problems that you are experiencing rather than add to a closed issue.

@[garethgreenaway](https://github.com/garethgreenaway) garethgreenaway closed this as [completed](https://github.com/saltstack/salt/issues?q=is%3Aissue+is%3Aclosed+archived%3Afalse+reason%3Acompleted) [on Sep 12, 2022](https://github.com/saltstack/salt/issues/62637#event-7372742837)

2022 is too long ago. I understand others added too, but it is bad practice to keep adding to closed issues, so long after they were closed. Once you have a new issue created, you can ping me to take a look at it.

jamest-pin commented 3 months ago

@dmurphy18 will do, but I think it is valid to add solutions to closed issues as they are often the top search result, this has often saved me in the past, finding a solution someone has added.

Especially when the issue is in fact still a problem for people, as we can see from the regular comments on this issue throughout 2023 and 2024, as recently as 21 June of this year (2024) which is only last month.

Something also very useful to me is when I commented on an issue, then months later after giving up, I get a notification someone has replied with a solution. I was extremely grateful to that person.

I will open a new issue.

MTecknology commented 3 months ago

@jamest-pin Please open a new issue for the problems that you are experiencing rather than add to a closed issue.
@[garethgreenaway](https://github.com/garethgreenaway) garethgreenaway closed this as [completed](https://github.com/saltstack/salt/issues?q=is%3Aissue+is%3Aclosed+archived%3Afalse+reason%3Acompleted) [on Sep 12, 2022](https://github.com/saltstack/salt/issues/62637#event-7372742837)
2022 is too long ago. I understand others added too, but it is bad practice to keep adding to closed issues, so long after they were closed. Once you have a new issue created, you can ping me to take a look at it.

In fairness, the problem described by the title has /not/ been resolved, and only the specific error in the description was addressed. Further discussion /has/ been related to the title, including a lack of understanding about why it was closed.

Unfortunately, this is a case where the root problem is unlikely to ever be addressed without forking the project, so the only effective approach is to make a new ticket for each individual issue this "solution" creates. You can also add a link to this issue when you create a new one, which will also add a reference here to the issue you create, which allows future readers of this thread to find the future issues created by the lack of resolving this issue.

dmurphy18 commented 3 months ago

@MTecknology This original issue relates to Salt 3005 which is EOL, the issue is almost 2 years old since it was closed. Hence just a simple request to open a new issue on a currently supported version of Salt is not too much to ask, with details as to the problem encountered.

saltstack / salt

[BUG] gitfs is suddenly a hassle with onedir package #62637