[Fix] Fix multi-asic flaky lldp not ready issue#9453
[Fix] Fix multi-asic flaky lldp not ready issue#9453yejianquan merged 2 commits intosonic-net:masterfrom
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:
|
|
@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