-
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] Salt 3006.2 requiring a higher timeout value than 3004.2 #65397
Comments
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.
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. |
having the same issue with salt-proxy's (napalm to nxos switches) since upgrading to 3006.x . previously 3004.x was our enviornment. |
I just updated to version 3006.4. It improved a little (a few seconds) but still got the timeout issue for a proxy located on Asia (180ms delay from master to proxy) |
Is it possible for either of you to come up with an example state in which I can test against both 3004 and 3006 to see the difference? That may help me identify the cause of the behavior you are seeing. |
@ntt-raraujo We fixed #65450 in 3006.5, can you test to see if that resolves this issue? |
@dwoz 3006.5 fixed the issue. Thanks! |
@dwoz Would you mind saying what the problem was? I couldn't find the issue on the release notes. |
It would also be great to know if its a master side change or minion side change |
@ntt-raraujo @ITJamie Sorry for the late reply on this. I've been tied up working on other issues and just got back to this one. The was caused by a regression where the file client get re-created on each state run. The overhead of creating a new connection to the master multiple times during a highstate caused a substantial slow down. The issue and fix were on the minion side. |
Fixed in 3006.5 |
Description
After implementing Salt 3006, the timeout had to be changed from 30 seconds to 60 seconds, otherwise, the error 'minion did not respond' would occur when applying highstates to proxy-minions
we currently have a 3004 deployment that works fine with 30 seconds timeout.
I'm using the same files on 3006 and 3004 servers. (same pillars, master file, states files, custom modules and so on). The only difference is the Salt version and OS
Setup
Please be as specific as possible and give set-up details.
Both 3004 and 3006 servers/proxies are on the same subnets and have the same virtual-resources/vm settings.
Steps to Reproduce the behavior
The first one with our current default timeout of 30 seconds, and the second one with 60 seconds timeout
Salt3004 version (same subnets and same files)
Expected behavior
A lower timeout gap between our 3004 and 3006 deployment.
Versions Report
salt --versions-report
(Provided by running salt --versions-report. Please also mention any differences in master/minion versions.)Additional context
Is there any other way to debug this issue? or a way to debug the zeromq itself to check for some transport issues?
The text was updated successfully, but these errors were encountered: