Skip to content
Draft
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
69 changes: 69 additions & 0 deletions feature/gnmi/otg_tests/gnmi_resiliency_test/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,69 @@
# gNMI-1.7: gNMI Resiliency Test

## Summary

- Generate High gNMI Load (get)
- Perform 1 LC OIR
- While LC is rebooting perform gNMI replace
- Operations should succeed once LC OIR completes
Comment on lines +3 to +8
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

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
  1. The test README.md should be structured following the test plan template, which specifies a paragraph-style summary. (link)


## Testbed type

* https://github.com/openconfig/featureprofiles/blob/main/topologies/atedut_2.testbed

## Procedure

#### Initial Setup:

* Connect DUT port-1, 2 to ATE port-1, 2
* Configure IPv4/IPv6 addresses on the ports

### 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
Comment on lines +21 to +24
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

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
  1. Each step in the test plan procedure should correspond to a comment or t.Log in the code. Numbered steps facilitate this mapping. (link)
  2. 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.


### gNMI-1.7.2: Trigger Line Card Reset

* While the gNMI load is active, trigger a reset of one of the line cards
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

need to specify how to do this. Probably gnoi.System.Reboot and specifying subcomponet name of the selected LINECARD

ref: https://github.com/openconfig/gnoi/blob/37f53d3adb3f95346b8d3cf8828ce29a60acce96/system/system.proto#L114


### gNMI-1.7.3: Execute gNMI Set (Replace) Operation

* While the line cards are initializing, perform a `gNMI Set` operation that modifies or replaces a significant portion of the configuration

### gNMI-1.7.4: Verification

* Validate if the `gNMI Set` request is successful or not
* Validate that the `gNMI get` at the root level works through out the test
* Validate that the `gNMI subscribe` works while the LC is operational

#### Canonical OC
```json
{
}
Comment on lines +42 to +43
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

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
  1. At least one 'Canonical OC' heading must be present with JSON content in the README representing the expected configuration. (link)

```

## Protocol/RPC Parameter Coverage

* gNMI
* Get
* Set

## Required DUT platform

* FFF
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

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.

Suggested change
* FFF
* MFF
References
  1. MFF is defined as a modular form factor device containing LINECARDs, which aligns with the test's intent to perform LC OIR. (link)


## OpenConfig Path and RPC Coverage

The below yaml defines the OC paths intended to be covered by this test. OC
paths used for test setup are not listed here.

```yaml
paths:
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

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
  1. The yaml stanza defines the OC paths intended to be covered by this test and is used for deriving test coverage. (link)
  2. 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.



rpcs:
gnmi:
gNMI.Set:
gNMI.Subscribe:
```
Loading