Fix for the syslog source ip test in the teardown of restore_config_by_config_reload.#17449
Merged
bingwang-ms merged 1 commit intosonic-net:masterfrom Mar 26, 2025
Merged
Conversation
The default connect_timeout is 5s, it's too long for checking the ssh down, ssh could has already recovered in the 5s.
Collaborator
|
/azp run |
|
Azure Pipelines will not run the associated pipelines, because the pull request was updated after the run command was issued. Review the pull request again and issue a new run command. |
JibinBao
approved these changes
Mar 11, 2025
liat-grozovik
approved these changes
Mar 13, 2025
Collaborator
|
/azpw run Azure.sonic-mgmt |
Contributor
Author
|
Hi @bingwang-ms , could you please review? |
Contributor
Author
|
/azpw run |
Collaborator
|
/AzurePipelines run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
bingwang-ms
approved these changes
Mar 26, 2025
amulyan7
pushed a commit
to amulyan7/sonic-mgmt
that referenced
this pull request
Mar 31, 2025
The default connect_timeout is 5s, it's too long for checking the ssh down, ssh could has already recovered in the 5s.
OriTrabelsi
pushed a commit
to OriTrabelsi/sonic-mgmt
that referenced
this pull request
Apr 1, 2025
The default connect_timeout is 5s, it's too long for checking the ssh down, ssh could has already recovered in the 5s.
opcoder0
pushed a commit
to opcoder0/sonic-mgmt
that referenced
this pull request
Dec 8, 2025
The default connect_timeout is 5s, it's too long for checking the ssh down, ssh could has already recovered in the 5s. Signed-off-by: opcoder0 <110003254+opcoder0@users.noreply.github.com>
gshemesh2
pushed a commit
to gshemesh2/sonic-mgmt
that referenced
this pull request
Dec 21, 2025
The default connect_timeout is 5s, it's too long for checking the ssh down, ssh could has already recovered in the 5s. Signed-off-by: Guy Shemesh <gshemesh@nvidia.com>
gshemesh2
pushed a commit
to gshemesh2/sonic-mgmt
that referenced
this pull request
Jan 26, 2026
The default connect_timeout is 5s, it's too long for checking the ssh down, ssh could has already recovered in the 5s. Signed-off-by: Guy Shemesh <gshemesh@nvidia.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description of PR
Summary:
There could be a failure in the teardown of tests/syslog/test_syslog_source_ip.py.
The reason is in restore_config_by_config_reload, there is a step to remove the vrf configured in the test, which will cause ssh flap.
There is a wait_for for the ssh down, but the default connect_timeout for ssh connection in the the wait_for is 5s, meaning if in 5s the ssh connection is restored, it will not consider the connection as down.
The 5s is too long, the ssh could have already been restored from the flap caused by removing the vrf, shorten it to 1s.
And the same for the wait_for in configure_mgmt_vrf_test_data.
Type of change
Back port request
Approach
What is the motivation for this PR?
Fix for the syslog source ip test in the teardown of restore_config_by_config_reload.
How did you do it?
How did you verify/test it?
Run the test, the failure didn't reproduce.
Any platform specific information?
Supported testbed topology if it's a new test case?
Documentation