-
Notifications
You must be signed in to change notification settings - Fork 743
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
Increase Orch CPU utilization timeout before link flap #16187
base: master
Are you sure you want to change the base?
Increase Orch CPU utilization timeout before link flap #16187
Conversation
This change was made because in modular chassis with multi-asic LCs, the link flap test might run on the uplink LC followed by the downlink LC. In such a scenario, the downlink LC will still be hot (above 10% utilization) before we flap its interfaces. Hence, the increase in timeout. We tested it with a timeout of 500 and it failed so we are increasing it to 600 which has been passing on our local T2 testbeds.
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
@arista-hpandya could you redefine the timeout in continuous link flap for T2? |
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
Hi @wenyiz2021 ! Thanks for reviewing this. I have made the changes to increase the timeout only for T2 devices. Also, on a side note happy new year! |
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.
small comment, otherwise lgtm
/Azp run Azure.sonic-mgmt |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
/azpw run Azure.sonic-mgmt |
/AzurePipelines run Azure.sonic-mgmt |
Azure Pipelines successfully started running 1 pipeline(s). |
/AzurePipelines run Azure.sonic-mgmt |
Azure Pipelines successfully started running 1 pipeline(s). |
This change was made because in modular chassis with multi-asic LCs, the link flap test might run on the uplink LC followed by the downlink LC. Since the uplink has a lot of neighbors the downlink CPU is busy re-routing the different pathways. In such a scenario, the downlink LC will still be hot (above 10% utilization) before we flap its interfaces. Hence, the increase in timeout.
We tested it with a timeout of 500 and it failed so we are increasing it to 600 which has been passing on our local T2 testbeds.
Description of PR
Summary:
Fixes #16186
Type of change
Back port request
Approach
What is the motivation for this PR?
To make sure that the timeout for the Orchagent CPU utilization check is large enough for the test to pass.
How did you do it?
Increased the timeout from 100 to 600.
How did you verify/test it?
Ran the test on T2 testbed with a timeout of 600 (Passed) and 500 (Failed)
Any platform specific information?
Supported testbed topology if it's a new test case?
Documentation