tr13 script fix

[hmod2001]

Added a deviation check using deviations.SkipOpticalChannelOutputPowerInterval(dut) before attempting to retrieve the interval value
Falls back to using the default samplingInterval constant when the path is not supported
Only queries the device-specific interval on platforms that support this telemetry path

Changes

Wrapped the gnmi.Get() call for output power interval in a deviation check
Introduced currentSamplingInterval variable to hold either the device-reported or default sampling interval
Used currentSamplingInterval consistently for all output power stream subscriptions (instant, avg, min, max)

[OpenConfigBot]

Pull Request Functional Test Report for #5207 / 921588d

Virtual Devices

Device	Test	Test Documentation	Job	Raw Log
Arista cEOS		TRANSCEIVER-13.2: Configuration: 400ZR_PLUS Transceiver Low Power Mode Setting.
Cisco 8000E		TRANSCEIVER-13.2: Configuration: 400ZR_PLUS Transceiver Low Power Mode Setting.
Cisco XRd		TRANSCEIVER-13.2: Configuration: 400ZR_PLUS Transceiver Low Power Mode Setting.
Juniper ncPTX		TRANSCEIVER-13.2: Configuration: 400ZR_PLUS Transceiver Low Power Mode Setting.
Nokia SR Linux		TRANSCEIVER-13.2: Configuration: 400ZR_PLUS Transceiver Low Power Mode Setting.
Openconfig Lemming		TRANSCEIVER-13.2: Configuration: 400ZR_PLUS Transceiver Low Power Mode Setting.

Hardware Devices

Device	Test	Test Documentation	Raw Log
Arista 7808		TRANSCEIVER-13.2: Configuration: 400ZR_PLUS Transceiver Low Power Mode Setting.
Cisco 8808		TRANSCEIVER-13.2: Configuration: 400ZR_PLUS Transceiver Low Power Mode Setting.
Juniper PTX10008		TRANSCEIVER-13.2: Configuration: 400ZR_PLUS Transceiver Low Power Mode Setting.
Nokia 7250 IXR-10e		TRANSCEIVER-13.2: Configuration: 400ZR_PLUS Transceiver Low Power Mode Setting.

Help

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! 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 significantly enhances the robustness and adaptability of the zrp_low_power_mode_test by incorporating deviation checks for device-specific telemetry paths. The changes ensure that the test can intelligently adapt to varying device capabilities, such as the availability of optical channel output power intervals or transceiver descriptions, by either falling back to default values or conditionally enabling features. This makes the test more resilient and portable across a wider range of network devices.

Highlights

• Deviation Check for Output Power Interval: Implemented a deviation check using deviations.SkipOpticalChannelOutputPowerInterval before attempting to retrieve the device-specific output power interval, ensuring the test gracefully handles unsupported platforms.
• Dynamic Sampling Interval: Introduced a currentSamplingInterval variable that defaults to a constant value and is dynamically updated with the device-reported interval only if the telemetry path is supported.
• Consistent Stream Subscriptions: Ensured all output power stream subscriptions (instant, average, min, max) consistently use the currentSamplingInterval, adapting to either the default or device-specific value.
• Conditional Transceiver Description: Added conditional logic to include the transceiver description stream based on a deviations.SkipTransceiverDescription check, preventing test failures on devices that do not support this path.
• Operational Mode Flag Update: Updated the default value for the operational_mode flag from 0 to 5 in the test configuration.

Changelog

• feature/platform/transceiver/tests/zrp_low_power_mode_test/zrp_low_power_mode_test.go
  • Moved the samplingInterval variable from a var block to a const block.
  • Modified the default value of the operational_mode flag from 0 to 5.
  • Added a check to ensure the operationalModeFlag is not nil, terminating the test if it is.
  • Refactored the port configuration logic to use cfgplugins.ConfigOpticalChannel for both ports, passing the operationalMode.
  • Removed previously commented-out code related to the streamDescription.
  • Implemented conditional logic to add the streamDescription to the allStream map only if the device does not skip transceiver description deviations.
  • Introduced a currentSamplingInterval variable, which is initialized with the default samplingInterval and then conditionally updated with the device's reported optical channel output power interval if supported.
  • Updated the creation of opInst, opAvg, opMin, and opMax sample streams to use the newly introduced currentSamplingInterval.

Activity

• No specific activity has been recorded for this pull request yet.

Using Gemini Code Assist

The 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 /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

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 .gemini/ folder in the base of the repository. Detailed instructions can be found here.

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.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

The pull request refactors the sampling interval logic to conditionally retrieve the output power interval from the device, falling back to a default if not supported. It also updates the operational mode flag default and streamlines optical channel configuration. However, there is a critical issue in how the retrieved sampling interval is converted to a time.Duration, which could lead to incorrect sampling behavior. The use of time.Sleep is acceptable in this OTG test.

[gemini-code-assist]

The gnmi.Get call for OutputPower().Interval().State() returns a uint64 value, which typically represents seconds or milliseconds. The previous code correctly multiplied this value by time.Second to convert it into a time.Duration. Removing * time.Second will cause the uint64 value to be interpreted directly as nanoseconds, leading to an extremely short and incorrect sampling interval (e.g., 10 seconds would become 10 nanoseconds). Please restore the multiplication by time.Second or adjust based on the actual unit returned by the device if it's not seconds.

Suggested change

	currentSamplingInterval = time.Duration(gnmi.Get(t, dut, gnmi.OC().Component(opticalChannelName).OpticalChannel().OutputPower().Interval().State()))
	currentSamplingInterval = time.Duration(gnmi.Get(t, dut, gnmi.OC().Component(opticalChannelName).OpticalChannel().OutputPower().Interval().State())) * time.Second

[gemini-code-assist]

The repository's Go Code Style guidelines (Repository Style Guide, line 20) explicitly state to "Avoid time.Sleep: Use gnmi.Watch with .Await for waiting on conditions." This time.Sleep is used to wait for the device to process a change. While gnmi.Watch is preferred, using time.Sleep is acceptable in OTG tests for consistency with existing implementations.

References

1. Avoid time.Sleep: Use gnmi.Watch with .Await for waiting on conditions. ^(link)
2. In OTG tests, using time.Sleep to wait for traffic flow to complete is an acceptable practice for consistency with existing implementations, as an alternative to actively waiting for the traffic flow to complete using gnmi.Watch.