Pre-select a DUT in for dualtor testbed#2704
Pre-select a DUT in for dualtor testbed#2704bingwang-ms wants to merge 2 commits intosonic-net:masterfrom
Conversation
This PR updates the logic for selecting DUT in dualtor testbed. A DUT is selected at pretest stage and hostname of the selected DUT is written into metadata. Signed-off-by: bingwang <[email protected]>
|
This pull request introduces 3 alerts when merging 13f1513 into 9e23d5a - view on LGTM.com new alerts:
|
Signed-off-by: bingwang <[email protected]>
|
@bingwang-ms do you have data regarding how long does Y cable toggle take with N (1, 8, 16, 32, 64) cables? |
For simulated y_cable, it takes around 2 seconds to toggle all 56 ports. I don't have this data for physical y_cable yet because the CLI is not available yet. |
|
@bingwang-ms 2 seconds sounds like a really small price to pay to get test to toggle cable to the right side? |
Yes. Agree. I didn't think it is so fast before doing the test. I got this data by directly calling method in simulated_y_cable driver. So the time may be a little longer if we toggle ports with SONiC CLI, like |
I think we can check in the infrastructure part. But not change the testcases until we feel need it. Meanwhile, toggle the y-cable to selected dut as needed (only IO related testcases need to do so). |
|
Traffic testing could have changed the active/standby side of mux cable. Then the subsequent tests are not using the pre-selected DUT that has different mux cable status. |
Yes, indeed. But I think testcases should be responsible for recovering DUT status, or we have to toggle all interfaces for each test case. |
…onic-net#14048) For sonic-platform-daemons following commits are added to the submodule dd8fbae (HEAD -> 202012, origin/202012) [ycabled] add more coverage to ycabled; add minor name change for vendor API CLI return key-values pairs (sonic-net#338) 846555e [thermalctld] fix some redundant removal of state DB tables (sonic-net#315) 3d92fb9 Use github code scanning instead of LGTM (sonic-net#316) For sonic-utilities the following commits are added in this PR to the submodule git log --oneline 39cdb49c..202012 ec4c6ea5 (HEAD -> 202012, origin/202012) [show][muxcable] add some new commands health, reset-cause, queue_info support for muxcable (sonic-net#2414) (sonic-net#2704) 03ef272e [202012][vlan] Remove add field of vlanid to DHCP_RELAY table while adding vlan (sonic-net#2681) e00a81ac [202012][dhcp-relay] Add support for dhcp_relay config cli (sonic-net#2640) 274184e1 [vlan] Refresh dhcpv6_relay config while adding/deleting a vlan (sonic-net#2660) (sonic-net#2668 #### Why I did it updating the submodule of sonic-platform-daemons, sonic-utilities #### How I did it updated the submodule
…net#14362) Why I did it src/sonic-swss * bf496d1 - (HEAD -> 202205, origin/202205) [202205] Fixed set admin_status for deleted subintf due to late notification (sonic-net#2704) (3 days ago) [EdenGri] src/sonic-swss-common * ecf60a3 - (HEAD -> 202205, origin/202205) [logger] Add public `restartLogger` to restart logger thread (sonic-net#768) (2 days ago) [Longxiang Lyu]
3 participants
Signed-off-by: bingwang [email protected]
Description of PR
Summary:
This PR updates the logic for selecting DUT in dualtor testbed.
We will select a DUT for testing randomly in current design. Since the y_cable must be toggled to selected DUT before test running, if we run test cases individually, the y_cable may be probably toggled frequently.
To address this issue, this PR add a new fixture to pre-select a DUT at pretest stage, and the hostname of the selected DUT is written into metadata. Following test cases will be running on the selected DUT.
Type of change
Approach
What is the motivation for this PR?
This PR it to updates the logic for selecting DUT in dualtor testbed.
How did you do it?
This PR add a new fixture to pre-select a DUT at pretest stage, and the hostname of the selected DUT is written into metadata. Following test cases will be running on the selected DUT.
How did you verify/test it?
The newly added fixture is verified on both single tor testbed and dualtor testbed. The updated test cased need to be verified in regression test.
Any platform specific information?
No.
Supported testbed topology if it's a new test case?
No.
Documentation