-
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
[BUG] Hourly presence change events received on master #64505
Comments
Possibly caused by #63941 |
We have the same issue here: Python Version: Dependency Versions: System Versions: Salt Master Version: Salt Version: Python Version: Dependency Versions: System Versions: About every hour all minions marked as "new" within event "/presence/changed" although there was no "lost" event before. We are using a python script as systemd service to alert us in case of presence change: import logging logging.basicConfig(format='%(asctime)s %(message)s', datefmt='%d.%m.%Y %H:%M:%S ', level=logging.INFO) opts = salt.config.client_config("/etc/salt/master/") event = salt.utils.event.get_event("master", sock_dir=opts["sock_dir"], opts=opts) for data in event.iter_events(tag="salt/presence/change"): |
Apologies, I need to update the tests for the fix in #64508 still then it should be ready to merge. My evenings will be busy for a while so I can't say when I will have time to do this |
Any news here? We handling every day 24 alerts because of this issue because we are checking the salt minion status with that event. |
Sorry, I have an infant taking up all my spare time :) There is only one test case needed to be added if I recall. I can write down what it is if you want to take a stab at it. It's possible it will require a logic change but I don't recall honestly, it's been to long |
You can always patch your master with the change from #64508, that is what I have done locally FWIW |
Description
We're currently running into the following with v3006.1: Regardless of any actual changes, the master receives
presence/change
every hour for all minions. This is not the behavior we had in v3002, and presence change events in our environment can trigger loads of orchestrate states to run, and all at once now.Setup
(Please provide relevant configs and/or SLS files (be sure to remove sensitive info. There is no general set-up of Salt.)
Please be as specific as possible and give set-up details.
Steps to Reproduce the behavior
debug logging:
Relevant master config:
Expected behavior
presence/change
events are only fired when minions are actually disconnected / gone or initiate a new TCP connectionScreenshots
If applicable, add screenshots to help explain your problem.
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: