Transceiver Onboarding Test Plan by mihirpat1 · Pull Request #10130 · sonic-net/sonic-mgmt

mihirpat1 · 2023-09-26T02:41:41Z

Description of PR

The "Transceiver Onboarding Test Plan" is created to layout a framework of tests so that any new transceiver which is being onboarded to SONiC can be validated with minimal user intervention. The test plan will also help in ensuring that any new transceiver to be onboarded is at par with the existing feature support on SONiC

Summary:
Fixes # (issue)

Type of change

Bug fix
Testbed and Framework(new/improvement)
Test case(new/improvement)

Back port request

201911
202012
202205

Approach

What is the motivation for this PR?

How did you do it?

How did you verify/test it?

Any platform specific information?

Supported testbed topology if it's a new test case?

Documentation

roy-sror

General question:

For no traffic tests- can they be supported on ptf-any toplogy?
For traffic test- would it be possible to add a traffic(no line rate) test for ptf-any?

keboliu · 2023-10-22T01:54:29Z

+- Check if any unexpected flags (such as LOS, LOL, DOM related warnings) are not set
+- Ensure firmware download, upgrade and downgrade works fine.
+- Verify that number of frames received is equal to number of frames sent in both northbound/southbound traffic flows for a predefined set period of time.
+- Verify traffic at line rate


traffic at line rate can be affected by other configurations, such as buffer, packet length, etc. Do you want to define a test with a set of specific configurations?

I have now removed the traffic test portion from the HLD. This was done to keep the test plan restricted to testing transceiver specific features.
A generic set of traffic tests should be run independently of the current test plan.

prgeor · 2023-12-27T17:28:50Z

@mihirpat1 can you add test case to ensure, during firmware download+Activiation there are no Xcvrd i2c bus access errors?

…boarding_test_plan

prgeor

@mihirpat1 Please add a separate test case for validating VDM

lguohan · 2024-07-18T18:03:54Z

+- **DOM Data**: Ensure Digital Optical Monitoring (DOM) data is correctly read and within acceptable ranges.
+- **Flags and Alerts**: Confirm no unexpected flags (e.g., Loss of Signal (LOS), Loss of Lock (LOL), DOM warnings) are set.
+- **Firmware Management**: Test firmware upgrade under various scenarios.
+- **Remote Reseat**: Verify support for remote reseat functionality.


we should also consider reboot tests, make sure the cable up after reboot.

do we test OIR behavior here?

do we also check temperature of the transceivers?

@lguohan
we should also consider reboot tests, make sure the cable up after reboot.
[MP] I have update the scope section to include device reboot scenarios.

do we test OIR behavior here?
[MP] Not currently. We have initiated conversation with vendor to help with pseudo OIR support.

do we also check temperature of the transceivers?
[MP] Yes, we are checking for temperature of transceivers to ensure it is within the temperature warning threshold.

During these link perturbation tests, we should confirm link status is expected and retrieve optical dom (tx, rx power, tx bias, voltage, case temperature, other VDM output), flags on optics, phy BER.

vvolam · 2024-07-18T18:51:38Z

+| Restart `syncd` | Validate transceiver re-initialization and link status post container restart | Ensure `xcvrd` restarts and the expected ports link up again, with port details visible in the LLDP table |
+| Perform a config reload | Test transceiver re-initialization and link status | Ensure `xcvrd` restarts and the expected ports link up again, with port details visible in the LLDP table |
+| Execute a cold reboot | Validate transceiver re-initialization and link status post-device reboot | Confirm the expected ports link up again post-reboot, with port details visible in the LLDP table |
+| Execute a warm reboot | Test link stability through the warm reboot | Ensure `xcvrd` restarts and maintains link stability for the interested ports, with their presence confirmed in the LLDP table |


Do we need a new test to check the link status after a firmware update?

@vvolam I think having the link status check as part of firmware update will ensure link stability is verified based on the relevant scenario being tested.

prgeor · 2024-07-25T14:54:10Z

@mihirpat1 please add one test case for checking optoe i2c error in dmesg log during firmware download

prgeor · 2024-07-25T15:24:18Z

@mihirpat1 do we have test for covering independent datapath behavior? shut/no-shut one one datapath should not impact the other. needed for breakout ports. For eg. Breakout 8x100G, we should do shut on 1st logical port and ensure no flap in port 2 to 8. Then shut on 2nd logical port and ensure no flap in port 1, 3 to 8 and so on. Finally in the reverse order, shut 8 then 7 and so on to shut 1.

… and modified the transciever_static_info.yml file to csv file

prgeor · 2025-02-11T20:56:08Z

@mihirpat1 also capture that the PN, SN, date code etc static field are NOT expected to change across firmware upgrade

…upgrade process

mssonicbld · 2025-02-11T21:21:48Z

/azp run

azure-pipelines · 2025-02-11T21:21:56Z

Azure Pipelines could not run because the pipeline triggers exclude this branch/path.

mihirpat1 · 2025-02-11T21:22:06Z

@mihirpat1 also capture that the PN, SN, date code etc static field are NOT expected to change across firmware upgrade

@prgeor I have addressed this now.

mssonicbld · 2025-02-12T19:24:53Z

/azp run

azure-pipelines · 2025-02-12T19:25:01Z

Azure Pipelines could not run because the pipeline triggers exclude this branch/path.

mssonicbld · 2025-02-12T19:27:02Z

/azp run

azure-pipelines · 2025-02-12T19:27:10Z

Azure Pipelines could not run because the pipeline triggers exclude this branch/path.

…th Tx disabled

mssonicbld · 2025-02-12T23:44:16Z

/azp run

azure-pipelines · 2025-02-12T23:44:24Z

Azure Pipelines could not run because the pipeline triggers exclude this branch/path.

qinchuanares · 2024-08-08T21:12:57Z

+- **DOM Data**: Ensure Digital Optical Monitoring (DOM) data is correctly read and within acceptable ranges.
+- **Flags and Alerts**: Confirm no unexpected flags (e.g., Loss of Signal (LOS), Loss of Lock (LOL), DOM warnings) are set.
+- **Firmware Management**: Test firmware upgrade under various scenarios.
+- **Remote Reseat**: Verify support for remote reseat functionality.


During these link perturbation tests, we should confirm link status is expected and retrieve optical dom (tx, rx power, tx bias, voltage, case temperature, other VDM output), flags on optics, phy BER.

qinchuanares · 2025-02-12T19:18:19Z

+- For breakout cables, ensure specific lanes are correctly modified by shut/no shut or other lane specific commands.
+
+**Optics Scope**:
+The test plan includes various optics types, such as:


shall we include 2*LR4, FR4, LR4 devices in the scope?

qinchuanares · 2025-02-12T19:19:00Z

+
+## Scope
+
+This test plan outlines a comprehensive framework for ensuring feature parity for new transceivers being onboarded to SONiC. The goal is to automate all tests listed in this document, covering the following areas:


Is there any place mentioning the sample size required for the transceiver onboarding process (SDVT)?

qinchuanares · 2025-02-12T19:23:19Z

+| Verify DOM information of the transceiver using CLI when interface is in shutdown and no shutdown state (if transceiver supports DOM) | Basic DOM validation | Ensure the fields are in line with the expectation based on interface shutdown/no shutdown state |
+| Verify EEPROM hexdump of the transceiver using CLI | Transceiver EEPROM hexdump validation | Ensure the output shows Lower Page (0h) and Upper Page (0h) for all 128 bytes on each page. Information from the transceiver dictionary created using the csv files can be used to validate contents of page 0h. Also, ensure that page 11h shows the Data Path state correctly |
+| Verify firmware version of the transceiver using CLI (requires disabling DOM config) | Firmware version validation | Ensure the active and inactive firmware version is in line with the expectation from the transceiver dictionary created using the csv files |
+| Verify different types of loopback | Transceiver loopback validation | Ensure that the various supported types of loopback work on the transceiver. The LLDP neighbor can also be used to verify the data path after enabling loopback (such as host-side input loopback) |


would like to emphasize that if per lane loopback feature is supported, we should also test the per-lane loopback feature and non-impacting to other non-loopback lanes.

qinchuanares · 2025-02-12T19:24:21Z

+| Issue CLI command to startup a port | Validate link status using CLI configuration | Ensure that the link is up and the port appears in the LLDP table. |
+| In a loop, issue startup/shutdown command 100 times | Stress test for link status validation | Ensure link status toggles to up/down appropriately with each startup/shutdown command. Verify ports appear in the LLDP table when the link is up |
+| Restart `xcvrd` | Test link and xcvrd stability | Confirm `xcvrd` restarts successfully without causing link flaps for the corresponding ports, and verify their presence in the LLDP table. Also ensure that xcvrd is up for at least 2 mins |
+| Induce I2C errors and restart `xcvrd` | Test link stability in case of `xcvrd` restart + I2C errors | Confirm `xcvrd` restarts successfully without causing link flaps for the corresponding ports, and verify their presence in the LLDP table |


How does one induce I2C errors?

qinchuanares · 2025-02-12T22:21:33Z

+| Step | Goal | Expected Results |
+|------|------|------------------|
+| Add `"skip_xcvrd": true,` to the `pmon_daemon_control.json` file and reboot the device | Ensure CMIS transceiver is in low power mode upon boot-up | Ensure the transceiver is in low power mode after device reboot. Revert back the file to original after verification |
+| Disable the Tx by directly writing to the EEPROM/or by calling `tx_disable` API | Ensure Tx is disabled within the advertised time for CMIS transceivers | Ensure that the DataPath state changes from DPActivated to a different state within the MaxDurationDPTxTurnOff time (page 1h, byte 168.7:4). Issue shut/no shutdown command to restore the link. This can be a stress test |


TX disable should move DP to initialized as a steady state, not any other states. We should explicitly clarify it.

qinchuanares · 2025-02-12T22:23:26Z

+| Add `"skip_xcvrd": true,` to the `pmon_daemon_control.json` file and reboot the device | Ensure CMIS transceiver is in low power mode upon boot-up | Ensure the transceiver is in low power mode after device reboot. Revert back the file to original after verification |
+| Disable the Tx by directly writing to the EEPROM/or by calling `tx_disable` API | Ensure Tx is disabled within the advertised time for CMIS transceivers | Ensure that the DataPath state changes from DPActivated to a different state within the MaxDurationDPTxTurnOff time (page 1h, byte 168.7:4). Issue shut/no shutdown command to restore the link. This can be a stress test |
+| Adjust FEC mode | Validate FEC mode adjustment for transceivers supporting FEC | Ensure that the FEC mode can be adjusted to different modes and revert to original FEC mode after testing |
+| Validate FEC stats counters | Validate FEC stats counters | Ensure that FEC correctable, uncorrectable and symbol errors have integer values |


Shall we add Prefec and PostFEC BER validation since the new release already supports this feature?

qinchuanares · 2025-02-12T22:25:14Z

+
+| Step | Goal | Expected Results |
+|------|------|------------------|
+| Adjust frequency | Validate frequency adjustment for C-CMIS transceivers | Ensure that the frequency can be adjusted to minimum and maximum supported frequency and revert to original frequency after testing |


should be tested on all the frequency grids supported/to be used in production.

qinchuanares · 2025-02-12T22:26:21Z

+| Step | Goal | Expected Results |
+|------|------|------------------|
+| Adjust frequency | Validate frequency adjustment for C-CMIS transceivers | Ensure that the frequency can be adjusted to minimum and maximum supported frequency and revert to original frequency after testing |
+| Adjust tx power | Validate tx power adjustment for C-CMIS transceivers | Ensure that the tx power can be adjusted to minimum and maximum supported power and revert to original tx power after testing |


should be tested during high power link up status, changing TX power from max to min advertised power or the other way around does not induce link flap.

qinchuanares · 2025-02-12T22:28:44Z

+Check transceiver status through CLI relying on redis-db and verify fields based on the below information
+
+```
+show int transceiver status <port>


could we also add new requirement for remote port (Z-side) status expectation when a local port (A-side) has port shutdown?

mihirpat1 · 2025-02-24T19:33:35Z

@mihirpat1 Add a testcase to check the page select byte functionality for transceiver supporting page select byte functionality.

mssonicbld · 2025-02-27T07:22:16Z

/azp run

azure-pipelines · 2025-02-27T07:22:23Z

Azure Pipelines could not run because the pipeline triggers exclude this branch/path.

…ttributes.csv

mssonicbld · 2025-02-27T18:06:21Z

/azp run

azure-pipelines · 2025-02-27T18:06:29Z

Azure Pipelines could not run because the pipeline triggers exclude this branch/path.

* Transceiver Onboarding Test Plan * Modified scope * Added details for pre-required file and elaborated testcases * Removed traffic test section * Added steps for DOM config, loopback operation and remote reseat * Added topology diagram and restructured the testcase details * Enhanced the contenet * Updated topology for server and modified CLI for dumping syslog * Added testcase for PM and VDM * Addressed PR comments, added new tests, added namespace option in CLI and modified the transciever_static_info.yml file to csv file * Removed shut/no shut for low power mode testcase * Enhanced steps in sfputil tests * Added more testcases * Modified expected result related to inactive firmware version during FW download failure * Modified expected results for firmware download testing * Added more info on transceiver metadata files * Modified Firmware Related Tests * Modified activation step to be executed for all subports * Added pre-requisite to have static info unchanged during te firmware upgrade process * Added VDM relevant TCs * Fixed typo in VDM section * Added VDM TC to test freeze and unfreeze with non-sequential lanes with Tx disabled * Added more details on transceiver inventory parsing * Added VDM and CDB background supported fields to transceiver_common_attributes.csv

### Description of PR  We need to add a parsing logic per the transceiver onboarding plan (section "Pre-requisites for the Below Tests") so that the transceiver specific data can be used to execute transceiver specific testcases. [Transceiver Onboarding Test Plan by mihirpat1 · Pull Request #10130 · sonic-net/sonic-mgmt](sonic-net/sonic-mgmt#10130) Summary: ### Type of change  - [ ] Bug fix - [x] Testbed and Framework(new/improvement) - [x] New Test case - [ ] Skipped for non-supported platforms - [ ] Test case improvement ### Back port request - [ ] 202012 - [ ] 202205 - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 ### Approach #### What is the motivation for this PR? Add parsing logic for transceiver inventory file. For the details of the parsing logic and the inventory file, please refer to section "Pre-requisites for the Below Tests" in [Transceiver Onboarding Test Plan by mihirpat1 · Pull Request #10130 · sonic-net/sonic-mgmt](sonic-net/sonic-mgmt#10130) #### How did you do it? 1. Added `transceiver_inventory` function with module scope to parse transceiver inventory file. 2. Created test_check_show_int_transceiver_eeprom function to test the parsing code and verify that the transceiver EEPROM of DUT is inline with the inventory data defined in `transceiver_common_attributes.csv` and `transceiver_dut_info.csv` files. The `test_ptp_show_intf_transceiver.py` is planned to be modified in future to have more testcases related to `show interfaces transceiver` related CLIs. 3. The current tests in `test_ptp_show_intf_transceiver.py` are applicable only to ptp-256 topology since the transceiver onboarding suite of tests is specific to ptp based topology. Future enhancements 1. We need to create an optimized way to find the logical port to physical port dictionary. Currently, this information is retrieved from the device via `get_physical_port_indices` and is time consuming since this function invokes the redis-db CLI equivalent to the number of logical ports on the DUT. 2. Additional logic to parse raw firmware binary and its metadata. #### How did you verify/test it? Test passed for `ptp-256` topology ``` patelmi@temp2:/var/src/mgmt_int/tests$ ./run_tests.sh -c $test_path -n $tb_name -i ../ansible/$tb_str,../ansible/veos -u -e "--skip_sanity --disable_loganalyzer" -t 'ptp-256' . ======================================================================= warnings summary ======================================================================== ../../../../usr/local/lib/python3.8/dist-packages/paramiko/transport.py:236 /usr/local/lib/python3.8/dist-packages/paramiko/transport.py:236: CryptographyDeprecationWarning: Blowfish has been deprecated "class": algorithms.Blowfish, -- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html ---------------------------------------------------- generated xml file: /var/src/mgmt_int/tests/logs/tr.xml ---------------------------------------------------- =========================================================== 1 passed, 1 warning in 244.13s (0:04:04) ============================================================ DEBUG:tests.conftest:[log_custom_msg] item: <Function test_check_show_int_transceiver_eeprom[str3-7060x6-64pe-4-None]> INFO:root:Can not get Allure report URL. Please check logs patelmi@temp2:/var/src/mgmt_int/tests$ ``` Test skipped for other topology ``` patelmi@temp2:/var/src/mgmt_int/tests$ ./run_tests.sh -c $test_path -n $tb_name -i ../ansible/$tb_str,../ansible/veos -u -e "--skip_sanity --disable_loganalyzer" -t 'ptp' === Running tests in groups === . transceiver/eeprom_tests/test_transceiver_eeprom.py::test_check_show_int_transceiver_eeprom[str3-7060x6-64pe-4-None] SKIPPED (test requires topology ...) [100%] ======================================================================= warnings summary ======================================================================== ../../../../usr/local/lib/python3.8/dist-packages/paramiko/transport.py:236 /usr/local/lib/python3.8/dist-packages/paramiko/transport.py:236: CryptographyDeprecationWarning: Blowfish has been deprecated "class": algorithms.Blowfish, -- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html ---------------------------------------------------- generated xml file: /var/src/mgmt_int/tests/logs/tr.xml ---------------------------------------------------- ==================================================================== short test summary info ==================================================================== SKIPPED [1] transceiver/eeprom_tests/test_transceiver_eeprom.py: test requires topology in Mark(name='topology', args=('ptp-256',), kwargs={}) ================================================================ 1 skipped, 1 warning in 32.67s ================================================================= DEBUG:tests.conftest:[log_custom_msg] item: <Function test_check_show_int_transceiver_eeprom[str3-7060x6-64pe-4-None]> INFO:root:Can not get Allure report URL. Please check logs patelmi@temp2:/var/src/mgmt_int/tests$ ``` #### Any platform specific information? #### Supported testbed topology if it's a new test case? `ptp-256` ### Documentation  https://github.com/sonic-net/sonic-mgmt/pull/10130/files?short_path=1707bc9#diff-1707bc9546f32667883a248c43fb8433faabd02ed0e09fe6bf430540ee4bea31 MSFT ADO - 31582995

…683)  ### Description of PR  We need to add a parsing logic per the transceiver onboarding plan (section "Pre-requisites for the Below Tests") so that the transceiver specific data can be used to execute transceiver specific testcases. [Transceiver Onboarding Test Plan by mihirpat1 · Pull Request #10130 · sonic-net/sonic-mgmt](sonic-net/sonic-mgmt#10130) Summary: ### Type of change  - [ ] Bug fix - [x] Testbed and Framework(new/improvement) - [x] New Test case - [ ] Skipped for non-supported platforms - [ ] Test case improvement ### Back port request - [ ] 202012 - [ ] 202205 - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 ### Approach #### What is the motivation for this PR? Add parsing logic for transceiver inventory file. For the details of the parsing logic and the inventory file, please refer to section "Pre-requisites for the Below Tests" in [Transceiver Onboarding Test Plan by mihirpat1 · Pull Request #10130 · sonic-net/sonic-mgmt](sonic-net/sonic-mgmt#10130) #### How did you do it? 1. Added `transceiver_inventory` function with module scope to parse transceiver inventory file. 2. Created test_check_show_int_transceiver_eeprom function to test the parsing code and verify that the transceiver EEPROM of DUT is inline with the inventory data defined in `transceiver_common_attributes.csv` and `transceiver_dut_info.csv` files. The `test_ptp_show_intf_transceiver.py` is planned to be modified in future to have more testcases related to `show interfaces transceiver` related CLIs. 3. The current tests in `test_ptp_show_intf_transceiver.py` are applicable only to ptp-256 topology since the transceiver onboarding suite of tests is specific to ptp based topology. Future enhancements 1. We need to create an optimized way to find the logical port to physical port dictionary. Currently, this information is retrieved from the device via `get_physical_port_indices` and is time consuming since this function invokes the redis-db CLI equivalent to the number of logical ports on the DUT. 2. Additional logic to parse raw firmware binary and its metadata. #### How did you verify/test it? Test passed for `ptp-256` topology ``` patelmi@temp2:/var/src/mgmt_int/tests$ ./run_tests.sh -c $test_path -n $tb_name -i ../ansible/$tb_str,../ansible/veos -u -e "--skip_sanity --disable_loganalyzer" -t 'ptp-256' . ======================================================================= warnings summary ======================================================================== ../../../../usr/local/lib/python3.8/dist-packages/paramiko/transport.py:236 /usr/local/lib/python3.8/dist-packages/paramiko/transport.py:236: CryptographyDeprecationWarning: Blowfish has been deprecated "class": algorithms.Blowfish, -- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html ---------------------------------------------------- generated xml file: /var/src/mgmt_int/tests/logs/tr.xml ---------------------------------------------------- =========================================================== 1 passed, 1 warning in 244.13s (0:04:04) ============================================================ DEBUG:tests.conftest:[log_custom_msg] item: <Function test_check_show_int_transceiver_eeprom[str3-7060x6-64pe-4-None]> INFO:root:Can not get Allure report URL. Please check logs patelmi@temp2:/var/src/mgmt_int/tests$ ``` Test skipped for other topology ``` patelmi@temp2:/var/src/mgmt_int/tests$ ./run_tests.sh -c $test_path -n $tb_name -i ../ansible/$tb_str,../ansible/veos -u -e "--skip_sanity --disable_loganalyzer" -t 'ptp' === Running tests in groups === . transceiver/eeprom_tests/test_transceiver_eeprom.py::test_check_show_int_transceiver_eeprom[str3-7060x6-64pe-4-None] SKIPPED (test requires topology ...) [100%] ======================================================================= warnings summary ======================================================================== ../../../../usr/local/lib/python3.8/dist-packages/paramiko/transport.py:236 /usr/local/lib/python3.8/dist-packages/paramiko/transport.py:236: CryptographyDeprecationWarning: Blowfish has been deprecated "class": algorithms.Blowfish, -- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html ---------------------------------------------------- generated xml file: /var/src/mgmt_int/tests/logs/tr.xml ---------------------------------------------------- ==================================================================== short test summary info ==================================================================== SKIPPED [1] transceiver/eeprom_tests/test_transceiver_eeprom.py: test requires topology in Mark(name='topology', args=('ptp-256',), kwargs={}) ================================================================ 1 skipped, 1 warning in 32.67s ================================================================= DEBUG:tests.conftest:[log_custom_msg] item: <Function test_check_show_int_transceiver_eeprom[str3-7060x6-64pe-4-None]> INFO:root:Can not get Allure report URL. Please check logs patelmi@temp2:/var/src/mgmt_int/tests$ ``` #### Any platform specific information? #### Supported testbed topology if it's a new test case? `ptp-256` ### Documentation  https://github.com/sonic-net/sonic-mgmt/pull/10130/files?short_path=1707bc9#diff-1707bc9546f32667883a248c43fb8433faabd02ed0e09fe6bf430540ee4bea31 MSFT ADO - 31582995

mihirpat1 added 3 commits September 16, 2023 04:28

Transceiver Onboarding Test Plan

5aa1a42

Modified scope

fbfab6b

Added details for pre-required file and elaborated testcases

ac1caab

mihirpat1 mentioned this pull request Sep 26, 2023

Transceiver Onboarding Test Plan #10056

Closed

6 tasks

mihirpat1 requested review from lguohan, moshemos, prgeor and roy-sror September 26, 2023 02:43

roy-sror requested a review from keboliu September 27, 2023 12:13

mihirpat1 marked this pull request as ready for review October 3, 2023 17:13

mihirpat1 requested review from wangxin and yxieca as code owners October 3, 2023 17:13

yxieca added the Test Plan label Oct 6, 2023

roy-sror reviewed Oct 10, 2023

View reviewed changes

keboliu reviewed Oct 22, 2023

View reviewed changes

Removed traffic test section

eaf0de4

mihirpat1 added 4 commits June 19, 2024 18:02

Merge branch 'master' of github.com:sonic-net/sonic-mgmt into xcvr_on…

37ab773

…boarding_test_plan

Added steps for DOM config, loopback operation and remote reseat

a22056d

Added topology diagram and restructured the testcase details

280af92

Enhanced the contenet

d8cda03

mihirpat1 force-pushed the xcvr_onboarding_test_plan branch from a49c432 to d8cda03 Compare July 15, 2024 21:54

Updated topology for server and modified CLI for dumping syslog

f55605b

prgeor reviewed Jul 17, 2024

View reviewed changes

Added testcase for PM and VDM

7e12314

lguohan reviewed Jul 18, 2024

View reviewed changes

vvolam reviewed Jul 18, 2024

View reviewed changes

Addressed PR comments, added new tests, added namespace option in CLI…

206b73e

… and modified the transciever_static_info.yml file to csv file

Added pre-requisite to have static info unchanged during te firmware …

ecb43ed

…upgrade process

Added VDM relevant TCs

69ea1d1

Fixed typo in VDM section

3f79d19

Added VDM TC to test freeze and unfreeze with non-sequential lanes wi…

b06e99d

…th Tx disabled

qinchuanares reviewed Feb 14, 2025

View reviewed changes

Added more details on transceiver inventory parsing

fd0a247

mihirpat1 mentioned this pull request Feb 27, 2025

Add parsing logic for transceiver inventory file #17215

Merged

11 tasks

Added VDM and CDB background supported fields to transceiver_common_a…

8648852

…ttributes.csv

prgeor approved these changes Feb 28, 2025

View reviewed changes

prgeor merged commit ab2b6c3 into sonic-net:master Feb 28, 2025

mssonicbld mentioned this pull request Sep 2, 2025

[action] [PR:17215] Add parsing logic for transceiver inventory file Azure/sonic-mgmt.msft#683

Merged

11 tasks


		## Scope

		This test plan outlines a comprehensive framework for ensuring feature parity for new transceivers being onboarded to SONiC. The goal is to automate all tests listed in this document, covering the following areas:

Conversation

mihirpat1 commented Sep 26, 2023

Description of PR

Type of change

Back port request

Approach

What is the motivation for this PR?

How did you do it?

How did you verify/test it?

Any platform specific information?

Supported testbed topology if it's a new test case?

Documentation

Uh oh!

roy-sror left a comment

Choose a reason for hiding this comment

Uh oh!

keboliu Oct 22, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

prgeor commented Dec 27, 2023

Uh oh!

prgeor left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

prgeor commented Jul 25, 2024

Uh oh!

prgeor commented Jul 25, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

prgeor commented Feb 11, 2025

Uh oh!

mssonicbld commented Feb 11, 2025

Uh oh!

azure-pipelines Bot commented Feb 11, 2025

Uh oh!

mihirpat1 commented Feb 11, 2025

Uh oh!

mssonicbld commented Feb 12, 2025

Uh oh!

azure-pipelines Bot commented Feb 12, 2025

Uh oh!

mssonicbld commented Feb 12, 2025

Uh oh!

azure-pipelines Bot commented Feb 12, 2025

Uh oh!

mssonicbld commented Feb 12, 2025

Uh oh!

azure-pipelines Bot commented Feb 12, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

keboliu Oct 22, 2023 •

edited

Loading

prgeor commented Jul 25, 2024 •

edited

Loading