[dual tor]: Move y cable simulator driver injection to pretest #2981
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Lawrence Lee <[email protected]>
Signed-off-by: Lawrence Lee <[email protected]>
yxieca
approved these changes
Feb 15, 2021
|
/AzurePipelines run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
wangxin
added a commit
to wangxin/sonic-mgmt
that referenced
this pull request
Nov 11, 2021
PR sonic-net#2981 moved injecting y-cable driver to dualtor DUTs from deploy-mg to a test case in test_pretest.py. This caused an chicken and egg problem. Initially without simulated y-cable driver or mux configuration in dualtor DUTs, the mux status is "unknown". When we run the test_pretest.py script to inject simulated y-cable driver or mux configuration, sanity check is performed by default. One of the check item is to check the mux simulator. Before simulated y-cable is injected/configured on dualtor DUTs, the muxcable status on DUTs would be "unknown" and mux simulator sanity check would fail after PR sonic-net#4640 was merged. Then test_pretest would not be able to inject simulated y-cable driver or configuration. This change: * Deprecated test case test_inject_y_cable_simulator_client in test_pretest.py. * Added back injecting simulated y-cable driver and configuration in "testbed-cli.sh deploy-mg". * Added extra light weighted tool "testbed-cli.sh config-y-cable" just for injecting simulated y-cable driver or mux configuration. Signed-off-by: Xin Wang <[email protected]>
4 tasks
wangxin
added a commit
that referenced
this pull request
Nov 12, 2021
…4676) PR #2981 moved injecting y-cable driver to dualtor DUTs from deploy-mg to a test case in test_pretest.py. This caused a chicken and egg problem. Initially without simulated y-cable driver or mux configuration in dualtor DUTs, the mux status is "unknown". When we run the test_pretest.py script to inject simulated y-cable driver or mux configuration, sanity check is performed by default. One of the check item is to check the mux simulator. Before simulated y-cable is injected/configured on dualtor DUTs, the muxcable status on DUTs would be "unknown" and mux simulator sanity check would fail after PR #4640 was merged. Then test_pretest would not be able to inject simulated y-cable driver or configuration. How did you do it? Changes: * Deprecated test case test_inject_y_cable_simulator_client in test_pretest.py. * Added back injecting simulated y-cable driver and configuration in "testbed-cli.sh deploy-mg". * Added extra light weighted tool "testbed-cli.sh config-y-cable" just for injecting simulated y-cable driver or mux configuration. Signed-off-by: Xin Wang <[email protected]>
AntonHryshchuk
pushed a commit
to AntonHryshchuk/sonic-mgmt
that referenced
this pull request
Jan 4, 2022
…onic-net#4676) PR sonic-net#2981 moved injecting y-cable driver to dualtor DUTs from deploy-mg to a test case in test_pretest.py. This caused a chicken and egg problem. Initially without simulated y-cable driver or mux configuration in dualtor DUTs, the mux status is "unknown". When we run the test_pretest.py script to inject simulated y-cable driver or mux configuration, sanity check is performed by default. One of the check item is to check the mux simulator. Before simulated y-cable is injected/configured on dualtor DUTs, the muxcable status on DUTs would be "unknown" and mux simulator sanity check would fail after PR sonic-net#4640 was merged. Then test_pretest would not be able to inject simulated y-cable driver or configuration. How did you do it? Changes: * Deprecated test case test_inject_y_cable_simulator_client in test_pretest.py. * Added back injecting simulated y-cable driver and configuration in "testbed-cli.sh deploy-mg". * Added extra light weighted tool "testbed-cli.sh config-y-cable" just for injecting simulated y-cable driver or mux configuration. Signed-off-by: Xin Wang <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Signed-off-by: Lawrence Lee [email protected]<!--
Please make sure you've read and understood our contributing guidelines;
https://github.com/Azure/SONiC/blob/gh-pages/CONTRIBUTING.md
Please provide following information to help code review process a bit easier:
-->
Description of PR
Summary:
Fixes # (issue)
Type of change
Approach
What is the motivation for this PR?
With manual image changes, the y_cable_simulator_client on dual ToR testbeds is overwritten. Currently, a new minigraph needs to be deployed to inject the client again, which has a lot of overhead and is not desirable.
How did you do it?
Create a test case in
test_pretest.pywhich creates and injects the simulator client to ToRs in a dual ToR topology.How did you verify/test it?
./run_tests.sh -n <testbed_name> -i <inventory files> -u -c test_pretest.py::test_inject_y_cable_simulator_clientVerify that the file gets placed into
/usr/lib/python3/dist-packagesinside the pmon container on both ToRs.Deploy minigraph, ensure that it completes successfully.
Any platform specific information?
Supported testbed topology if it's a new test case?
Documentation