[BUG] mine.get not work when scheduled
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 15.7k
- Forks
- 5.6k
- Avg merge
- 2d 44m
- Merged PRs (30d)
- 80
Description
Greetings,
Description
Posted this issue here with all the details: https://groups.google.com/g/salt-users/c/s51O4nkwrog
On that post I basically narrowed it down to where my issue was. (mine.get function)
In the real world, I have a custom module and inside that module I run a mine.get function to get data from another minion to do something on the current minion.
That custom function has been working well since v3004.x. I even tried to see if I can get around it by using a reactor but still get the same logs as posted in the Google Groups ticket.
At least right now, I had to create cron job on the salt master server to execute salt -N group custom_module.main and that is working fine.
Setup
See google groups ticket. I can post again here if desires.
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 (Docker on salt master)
- or a combination (minions on pypi venv)
- jails if it is FreeBSD
- classic packaging
- onedir packaging
- used bootstrap to install
Steps to Reproduce the behavior
Move minion to v3006.x and scheduled mine function works fine. Move to v3007.x and problem starts.
Expected behavior
Mine function should pass
Versions Report
minion:
Salt Version:
Salt: 3007.1
Python Version:
Python: 3.11.7 (main, Jul 4 2024, 00:00:00) [GCC 11.4.1 20231218 (Red Hat 11.4.1-3)]
Dependency Versions:
cffi: 1.17.0
cherrypy: 18.10.0
dateutil: 2.9.0.post0
docker-py: 7.1.0
gitdb: Not Installed
gitpython: Not Installed
Jinja2: 3.1.4
libgit2: Not Installed
looseversion: 1.3.0
M2Crypto: Not Installed
Mako: Not Installed
msgpack: 1.0.8
msgpack-pure: Not Installed
mysql-python: Not Installed
packaging: 24.1
pycparser: 2.22
pycrypto: Not Installed
pycryptodome: 3.20.0
pygit2: Not Installed
python-gnupg: 0.5.2
PyYAML: 6.0.2
PyZMQ: 26.2.0
relenv: Not Installed
smmap: Not Installed
timelib: 0.3.0
Tornado: 6.4.1
ZMQ: 4.3.5
Salt Extensions:
saltext.prometheus: 2.1.0
saltext.vault: 1.1.1
Salt Package Information:
Package Type: Not Installed
System Versions:
dist: rocky 9.4 Blue Onyx
locale: utf-8
machine: x86_64
release: 5.14.0-427.28.1.el9_4.x86_64
system: Linux
version: Rocky Linux 9.4 Blue Onyx
master (inside docker container, prebuilt pypi image)
Salt Version:
Salt: 3007.1
Python Version:
Python: 3.11.9 (main, Aug 2 2024, 14:46:25) [GCC 13.2.1 20240309]
Dependency Versions:
cffi: 1.17.0
cherrypy: 18.10.0
dateutil: 2.9.0.post0
docker-py: Not Installed
gitdb: Not Installed
gitpython: Not Installed
Jinja2: 3.1.4
libgit2: Not Installed
looseversion: 1.3.0
M2Crypto: Not Installed
Mako: Not Installed
msgpack: 1.0.8
msgpack-pure: Not Installed
mysql-python: Not Installed
packaging: 24.1
pycparser: 2.22
pycrypto: Not Installed
pycryptodome: 3.20.0
pygit2: Not Installed
python-gnupg: 0.5.2
PyYAML: 6.0.2
PyZMQ: 26.2.0
relenv: Not Installed
smmap: Not Installed
timelib: 0.3.0
Tornado: 6.4.1
ZMQ: 4.3.5
Salt Extensions:
salt-nornir: 0.21.0
saltext.prometheus: 2.1.0
saltext.vault: 1.1.1
Salt Package Information:
Package Type: Not Installed
System Versions:
dist: alpine 3.20.2
locale: utf-8
machine: x86_64
release: 5.14.0-427.31.1.el9_4.x86_64
system: Linux
version: Alpine Linux 3.20.2
I believe the mine.get function is broken when scheduled.
Please let me know if I missed something in my investigation/reporting.
Thank you for the support!
Best,
Dave
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the linked Google Groups report and the behavior described for the custom module's scheduled mine.get call. Reproduce the regression by comparing scheduled execution between Salt 3006.x and 3007.x in the listed minion and master setup; done means the scheduled mine function passes as it did in 3006.x.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, python
- Domain
- devops, infrastructure
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100