-
Notifications
You must be signed in to change notification settings - Fork 320
Add DEBUG_DROP_MONITOR table to schema.h #971
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
Add DEBUG_DROP_MONITOR table to schema.h #971
Conversation
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
FengPan-Frank
left a comment
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
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azpw run Azure.sonic-swss |
|
/AzurePipelines run Azure.sonic-swss |
|
No pipelines are associated with this pull request. |
|
@arista-hpandya please rebase. |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
The vstest failure is unrelated to the change, can we override the warnings and go ahead with the merge? |
|
Please rebase and re-run pipeline. |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
The failures are because of an outdated libyang version: Enhancement to libyang3 is being tracked here: sonic-net/sonic-buildimage#22385 Since this particular change is harmless and irrelevant to the failure could we merge this in? This is a dependency of sonic-net/sonic-swss#3509 and its waiting on this being merged. cc: @vmittal-msft |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
6f6a47c
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
@arista-hpandya please resolve conflicts. |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
@vmittal-msft the semgrep needs maintainer approval without which it gets stuck, all tests have passed and this can be merged:
|
|
@vmittal-msft @rlhui @yxieca All tests have passed could we merge this please, thanks! |
…onitoring feature (#3509) * Add support for configurable debug drop monitoring feature Note: This change depends on sonic-net/sonic-swss-common#971 Fixes #3501 HLD: sonic-net/SONiC#1912 What I did Added logic to read configuration from the DEBUG_DROP_MONITOR table. Added logic to register persistent alerts when the conditions are met. Added logic to toggle the feature off if desired on a per-counter level. Why I did it To implement the persistent drop counter monitoring feature which allows users to configure thresholds for drop counters and register alerts when persistent drops are detected. How I verified it Existing unit tests were run using make check to ensure no functionality was affected. New unit tests have been added to verify the functionality. Manual testing was performed on a SONiC switch to verify that the orchagent correctly reads the configuration, generates alerts when thresholds are met, and can be toggled off/on.
…onitoring feature (sonic-net#3509) * Add support for configurable debug drop monitoring feature Note: This change depends on sonic-net/sonic-swss-common#971 Fixes sonic-net#3501 HLD: sonic-net/SONiC#1912 What I did Added logic to read configuration from the DEBUG_DROP_MONITOR table. Added logic to register persistent alerts when the conditions are met. Added logic to toggle the feature off if desired on a per-counter level. Why I did it To implement the persistent drop counter monitoring feature which allows users to configure thresholds for drop counters and register alerts when persistent drops are detected. How I verified it Existing unit tests were run using make check to ensure no functionality was affected. New unit tests have been added to verify the functionality. Manual testing was performed on a SONiC switch to verify that the orchagent correctly reads the configuration, generates alerts when thresholds are met, and can be toggled off/on.
…onitoring feature (sonic-net#3509) * Add support for configurable debug drop monitoring feature Note: This change depends on sonic-net/sonic-swss-common#971 Fixes sonic-net#3501 HLD: sonic-net/SONiC#1912 What I did Added logic to read configuration from the DEBUG_DROP_MONITOR table. Added logic to register persistent alerts when the conditions are met. Added logic to toggle the feature off if desired on a per-counter level. Why I did it To implement the persistent drop counter monitoring feature which allows users to configure thresholds for drop counters and register alerts when persistent drops are detected. How I verified it Existing unit tests were run using make check to ensure no functionality was affected. New unit tests have been added to verify the functionality. Manual testing was performed on a SONiC switch to verify that the orchagent correctly reads the configuration, generates alerts when thresholds are met, and can be toggled off/on.

What I did
DEBUG_DROP_MONITORtable definition tosonic-swss-common.Why I did it
This change is a prerequisite for another PR (sonic-net/sonic-swss#3509) that relies on using the
DEBUG_DROP_MONITORtable in the orchagent for persistent drop counter monitoring.How I verified it
NA
Details if related
This PR only adds the table definition. The logic to read, process, and act upon the data in this table is implemented in a PR linked above.
Fixes #972
HLD: sonic-net/SONiC#1912