-
Notifications
You must be signed in to change notification settings - Fork 717
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
[Fix] Fix multi-asic flaky lldp not ready issue #9453
[Fix] Fix multi-asic flaky lldp not ready issue #9453
Conversation
e5c9099
to
a46d913
Compare
The pre-commit check detected issues in the files touched by this pull request. Detailed pre-commit check results: To run the pre-commit checks locally, you can follow below steps:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@yejianquan PR conflicts with 202012 branch |
@yejianquan PR conflicts with 202205 branch |
Description of PR In the recover of sanity check, for config_reload, we simply sleep 120s. In some topology, like multi-asic scenario, it's not enough. lldp services get a big chance that not ready after 120s, then sanity failed. Use config_reload with safe_reload to better handle this flaky issue. Approach What is the motivation for this PR? Fix multi-asic lldp flaky issue. How did you do it? Use config_reload with safe_reload to better handle this flaky issue. co-authorized by: jianquanye@microsoft.com
Cherry-pick PR to 202305: #9476 |
Description of PR In the recover of sanity check, for config_reload, we simply sleep 120s. In some topology, like multi-asic scenario, it's not enough. lldp services get a big chance that not ready after 120s, then sanity failed. Use config_reload with safe_reload to better handle this flaky issue. Approach What is the motivation for this PR? Fix multi-asic lldp flaky issue. How did you do it? Use config_reload with safe_reload to better handle this flaky issue. co-authorized by: jianquanye@microsoft.com
Description of PR In the recover of sanity check, for config_reload, we simply sleep 120s. In some topology, like multi-asic scenario, it's not enough. lldp services get a big chance that not ready after 120s, then sanity failed. Use config_reload with safe_reload to better handle this flaky issue. Approach What is the motivation for this PR? Fix multi-asic lldp flaky issue. How did you do it? Use config_reload with safe_reload to better handle this flaky issue. co-authorized by: jianquanye@microsoft.com
|
|
cherry-pick #9453 Description of PR In the recover of sanity check, for config_reload, we simply sleep 120s. In some topology, like multi-asic scenario, it's not enough. lldp services get a big chance that not ready after 120s, then sanity failed. Use config_reload with safe_reload to better handle this flaky issue. Approach What is the motivation for this PR? Fix multi-asic lldp flaky issue. How did you do it? Use config_reload with safe_reload to better handle this flaky issue. co-authorized by: jianquanye@microsoft.com
cherry-pick #9453 Description of PR In the recover of sanity check, for config_reload, we simply sleep 120s. In some topology, like multi-asic scenario, it's not enough. lldp services get a big chance that not ready after 120s, then sanity failed. Use config_reload with safe_reload to better handle this flaky issue. Approach What is the motivation for this PR? Fix multi-asic lldp flaky issue. How did you do it? Use config_reload with safe_reload to better handle this flaky issue. co-authorized by: jianquanye@microsoft.com Co-authored-by: Ye Jianquan <jianquanye@microsoft.com>
Cherry-pick: #9453 Description of PR In the recover of sanity check, for config_reload, we simply sleep 120s. In some topology, like multi-asic scenario, it's not enough. lldp services get a big chance that not ready after 120s, then sanity failed. Use config_reload with safe_reload to better handle this flaky issue. Approach What is the motivation for this PR? Fix multi-asic lldp flaky issue. How did you do it? Use config_reload with safe_reload to better handle this flaky issue. co-authorized by: jianquanye@microsoft.com
Description of PR In the recover of sanity check, for config_reload, we simply sleep 120s. In some topology, like multi-asic scenario, it's not enough. lldp services get a big chance that not ready after 120s, then sanity failed. Use config_reload with safe_reload to better handle this flaky issue. Approach What is the motivation for this PR? Fix multi-asic lldp flaky issue. How did you do it? Use config_reload with safe_reload to better handle this flaky issue. co-authorized by: jianquanye@microsoft.com
Description of PR
In the recover of sanity check, for config_reload, we simply sleep 120s.
In some topology, like multi-asic scenario, it's not enough.
lldp services get a big chance that not ready after 120s, then sanity failed.
Use config_reload with safe_reload to better handle this flaky issue.
Summary:
Fixes # (issue)
Type of change
Back port request
Approach
What is the motivation for this PR?
Fix multi-asic lldp flaky issue.
How did you do it?
Use config_reload with safe_reload to better handle this flaky issue.
How did you verify/test it?
Any platform specific information?
Supported testbed topology if it's a new test case?
Documentation