Adding gnmi resiliency test#5389
Conversation
rohit-rp
commented
Apr 28, 2026
rohit-rp
commented
- Generate High gNMI Load (get)
- Perform 1 LC OIR
- While LC is rebooting perform gNMI replace
- Operations should succeed once LC OIR completes
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 introduces documentation for a new gNMI resiliency test case. The test is designed to verify system stability by performing gNMI operations while a line card undergoes an OIR (Online Insertion and Removal) event. 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 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 counter productive. 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
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a new test plan for gNMI resiliency, detailing procedures for high load testing and line card resets. The review feedback identifies several necessary improvements to the README.md to comply with project standards: the summary needs to be a paragraph rather than a list, the procedure steps should use ordered numbering for easier mapping to test logs, and the 'Canonical OC' and 'paths' sections must be populated with relevant data. Additionally, the DUT platform requirement should be changed from FFF to MFF to reflect the hardware capabilities needed for line card OIR tests.
| ## Summary | ||
|
|
||
| - Generate High gNMI Load (get) | ||
| - Perform 1 LC OIR | ||
| - While LC is rebooting perform gNMI replace | ||
| - Operations should succeed once LC OIR completes |
There was a problem hiding this comment.
The summary should be written as a few sentences or paragraphs describing the purpose and scope of the test, rather than a bulleted list of steps. This follows the structure defined in the test plan template.
References
- The test README.md should be structured following the test plan template, which specifies a paragraph-style summary. (link)
| ### gNMI-1.7.1: Generate High gNMI Load | ||
|
|
||
| * Perform a `gNMI Get` at the root level every 60 seconds or less | ||
| * Set up gNMI subscribe with `SAMPLE` mode and sample interval of 10 second for interface counters |
There was a problem hiding this comment.
To ensure that each step in the test plan procedure corresponds clearly to a comment or t.Log in the code, please use an ordered list instead of bullet points. Note that in Markdown, it is acceptable to use '1.' for all items as the renderer will automatically create a sequential list, making manual sequencing unnecessary.
References
- Each step in the test plan procedure should correspond to a comment or t.Log in the code. Numbered steps facilitate this mapping. (link)
- In Markdown, it is acceptable to use '1.' for all items in an ordered list. The renderer will automatically create a sequential list, so manually sequencing the numbers in the source is not necessary.
| { | ||
| } |
There was a problem hiding this comment.
The 'Canonical OC' section must contain the JSON formatted OpenConfig configuration that is expected to be generated or used by the test. An empty JSON object is insufficient.
References
- At least one 'Canonical OC' heading must be present with JSON content in the README representing the expected configuration. (link)
|
|
||
| ## Required DUT platform | ||
|
|
||
| * FFF |
There was a problem hiding this comment.
The test procedure involves Line Card (LC) OIR and resets. This functionality typically requires a Modular Form Factor (MFF) device rather than a Fixed Form Factor (FFF) device.
| * FFF | |
| * MFF |
References
- MFF is defined as a modular form factor device containing LINECARDs, which aligns with the test's intent to perform LC OIR. (link)
| paths used for test setup are not listed here. | ||
|
|
||
| ```yaml | ||
| paths: |
There was a problem hiding this comment.
The 'paths' section in the YAML coverage stanza is empty. Please list the OpenConfig paths intended to be covered by this test, such as interface counters mentioned in the procedure. Defining them here ensures they are tracked in a structured format.
References
- The yaml stanza defines the OC paths intended to be covered by this test and is used for deriving test coverage. (link)
- In README files, avoid duplicating lists of paths if they are already clearly defined in a structured format, such as a YAML section, within the same document.
|
|
||
| ### gNMI-1.7.2: Trigger Line Card Reset | ||
|
|
||
| * While the gNMI load is active, trigger a reset of one of the line cards |
There was a problem hiding this comment.
need to specify how to do this. Probably gnoi.System.Reboot and specifying subcomponet name of the selected LINECARD
3 participants
