-
Notifications
You must be signed in to change notification settings - Fork 739
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
[syslog] enable/disable syslog rate limit feature in fixture #10986
[syslog] enable/disable syslog rate limit feature in fixture #10986
Conversation
Change-Id: I61545db602d579fa0f337686427235c6d04998c7
@Junchao-Mellanox the dependency is not accurate. can you please share the dependent PR? |
Updated |
Hi @StormLiangMS , could you help merge it in 202305? This should be the fix of ADO: 25971560 |
…et#10986) Feature syslog rate limit has been disabled by default to avoid consume CPU cycles during warm / fast reboot. There are new CLIs to enable/disable it. The PR is to automatically enable it before syslog rate limit test and disable it after. Summary: In fixture "restore_rate_limit", enable the feature at beginning, disable the feature at the end. Change-Id: I61545db602d579fa0f337686427235c6d04998c7
Cherry-pick PR to 202305: #11315 |
@Junchao-Mellanox @wen587 do we need this for 202311? |
yes |
Feature syslog rate limit has been disabled by default to avoid consume CPU cycles during warm / fast reboot. There are new CLIs to enable/disable it. The PR is to automatically enable it before syslog rate limit test and disable it after. Summary: In fixture "restore_rate_limit", enable the feature at beginning, disable the feature at the end. Change-Id: I61545db602d579fa0f337686427235c6d04998c7
This PR was merged before 202311 branch was created from master branch. No need to cherry-pick for 202311 branch. |
Depending on sonic-net/sonic-buildimage#17458
Description of PR
Feature syslog rate limit has been disabled by default to avoid consume CPU cycles during warm / fast reboot. There are new CLIs to enable/disable it. The PR is to automatically enable it before syslog rate limit test and disable it after.
Summary:
In fixture "restore_rate_limit", enable the feature at beginning, disable the feature at the end.
Type of change
[ ] Bug fix
[ ] Testbed and Framework(new/improvement)
[x] Test case(new/improvement)
Back port request
[ ] 201911
[ ] 202012
[ ] 202205
[x] 202305
Approach
In fixture "restore_rate_limit", enable the feature at beginning, disable the feature at the end.
What is the motivation for this PR?
Align test code with production code change
How did you do it?
In fixture "restore_rate_limit", enable the feature at beginning, disable the feature at the end.
How did you verify/test it?
Run test case on local setup, all passed
Any platform specific information?
N/A
Supported testbed topology if it's a new test case?
N/A
Documentation