[RT-7.1] Fix telemetry data validation using gnmi ON_CHANGE stream mode#5674
[RT-7.1] Fix telemetry data validation using gnmi ON_CHANGE stream mode#5674sriram-arista wants to merge 1 commit into
Conversation
Issue: Currently the test validates that some prefix telemetry data on the dut based on the leaf node and the inbound/outbound policy applied. The test fails sometimes when the gnmi.Watch call timesout/returning with a value that doesn't satisfy the condition in the predicate passed. Root cause: The default stream mode being TARGET_DEFINED, the gnmi.Watch lets the target to decide how the stream updates have to be sent. Arista has a set of pre-configured list of nodes that are considered to be chatty (rapidly changing). To avoid sending frequent updates in the stream, the device will SAMPLE the updates and send them in the stream. Arista devices have a default SAMPLE rate of 30 secs. Fix: Usage of the ON_CHANGE stream mode in gnmi.Watch so that all the updates within the timeout window are received in the test, to avoid timing failures.
Pull Request Functional Test Report for #5674 / e48bfb1Virtual Devices
Hardware Devices
|
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request addresses intermittent telemetry validation failures in BGP policy tests. By switching from the default TARGET_DEFINED stream mode to ON_CHANGE, the tests can now reliably capture rapid updates that were previously being sampled and missed by the default 30-second sampling interval on certain devices. The changes include adding a new platform deviation to control this behavior and updating the relevant test suite to apply these options. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request introduces a new deviation, StreamSubscriptionModeOnChangeRequired, which allows tests to request ON_CHANGE subscription mode for frequently updated OpenConfig leaf nodes to prevent timing failures on certain devices. This deviation is integrated into the BGP default policies test. The feedback requests adding a tracking issue URL to the new deviation accessor function's comment in internal/deviations/deviations.go, as required by the repository style guide.
| // StreamSubscriptionModeOnChangeRequired returns true if the device requires | ||
| // ON_CHANGE subscription mode for frequently updated OC leaf nodes instead of | ||
| // TARGET_DEFINED. With TARGET_DEFINED, some devices defer SAMPLE updates for | ||
| // significant time, causing timing failures when a test checks a such a rapidly | ||
| // changing value with a timeout lesser than the SAMPLE rate. | ||
| func StreamSubscriptionModeOnChangeRequired(dut *ondatra.DUTDevice) bool { |
There was a problem hiding this comment.
According to the repository style guide, every deviation accessor function must include a comment containing a URL link to an issue tracker (e.g., https://issuetracker.google.com/xxxxx or a GitHub issue) to document and track the behavior or eventual removal of the deviation. Please add a tracking issue URL to the comment.
// StreamSubscriptionModeOnChangeRequired returns true if the device requires
// ON_CHANGE subscription mode for frequently updated OC leaf nodes instead of
// TARGET_DEFINED. With TARGET_DEFINED, some devices defer SAMPLE updates for
// significant time, causing timing failures when a test checks a such a rapidly
// changing value with a timeout lesser than the SAMPLE rate.
//
// See: https://github.com/openconfig/featureprofiles/issues/xxxxx
func StreamSubscriptionModeOnChangeRequired(dut *ondatra.DUTDevice) bool {References
- Every deviation accessor function must include a comment containing a URL link to an issue tracker (e.g., https://issuetracker.google.com/xxxxx) to document and track the behavior. (link)
- Every deviation accessor function, including those for permanent deviations, must include a comment with a URL link to an issue tracker (e.g., a tracking FR) to document and track the behavior.
Issue:
Currently the test validates that some prefix telemetry data on the dut based on the leaf node and the inbound/outbound policy applied. The test fails sometimes when the gnmi.Watch call timesout/returning with a value that doesn't satisfy the condition in the predicate passed.
Root cause:
The default stream mode being TARGET_DEFINED, the gnmi.Watch lets the target to decide how the stream updates have to be sent. Arista has a set of pre-configured list of nodes that are considered to be chatty (rapidly changing). To avoid sending frequent updates in the stream, the device will SAMPLE the updates and send them in the stream. Arista devices have a default SAMPLE rate of 30 secs.
Fix:
Usage of the ON_CHANGE stream mode in gnmi.Watch so that all the updates within the timeout window are received in the test, to avoid timing failures.