[dualtor]: Mock all y_cable methods for mux sim #3242
Merged
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]>
theasianpianist
force-pushed
the
y_cable_sim_mock
branch
from
6b462c3 to
611976a
Compare
|
Do not merge until #3198 is merged |
vdahiya12
reviewed
Mar 31, 2021
| @@ -269,3 +277,125 @@ def check_if_link_is_active_for_torB(physical_port): | |||
| """ | |||
| return True | |||
|
|
|||
| def enable_prbs_mode(physical_port, target, mode_value, lane_map): | |||
There was a problem hiding this comment.
i would suggest putting a generic note for all these dummy values, so as to ensure that this needs to be corrected in future. suggest putting a TODO as well.
There was a problem hiding this comment.
What needs to be done in the future? Since these hardware constructs don't exist for the simulator shouldn't we always use these dummy values?
There was a problem hiding this comment.
If we enable /disable loopback or prbs then normal traffic cannot run. I dont know how exactly you can accomplish this with simulator.
There was a problem hiding this comment.
Is this something that would be used during normal operation?
wangxin
reviewed
Mar 31, 2021
| @@ -172,7 +180,7 @@ def _post(physical_port, data): | |||
| return False | |||
| return True | |||
|
|
|||
| def _get(physical_port): | |||
| def _get(physical_port, action=None): | |||
There was a problem hiding this comment.
Why add this action argument? I don't see that it is used.
There was a problem hiding this comment.
I think it's used for flap counter in line 335
bingwang-ms
approved these changes
Mar 31, 2021
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/Azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
wangxin
approved these changes
Apr 1, 2021
nirmalya-keysight
pushed a commit
to nirmalya-keysight/sonic-mgmt
that referenced
this pull request
Apr 5, 2021
What is the motivation for this PR? XCVRD runs some methods which attempt to read from cable hardware. This hardware doesn't exist for mux simulator, so XCVRD writes many errors to the syslog. How did you do it? Implement mocks for all methods in sonic_y_cable to prevent errors from being generated. How did you verify/test it? Inject new mux_simulator_client to dual ToR device with changes from sonic-net/sonic-platform-common#181. Verify PMON and mux containers stay up, and show mux status output looks normal. Initiate CLI switchover and confirm show mux status output reflects switchover. Signed-off-by: Lawrence Lee <[email protected]>
saravanansv
pushed a commit
to saravanansv/sonic-mgmt
that referenced
this pull request
May 6, 2021
What is the motivation for this PR? XCVRD runs some methods which attempt to read from cable hardware. This hardware doesn't exist for mux simulator, so XCVRD writes many errors to the syslog. How did you do it? Implement mocks for all methods in sonic_y_cable to prevent errors from being generated. How did you verify/test it? Inject new mux_simulator_client to dual ToR device with changes from sonic-net/sonic-platform-common#181. Verify PMON and mux containers stay up, and show mux status output looks normal. Initiate CLI switchover and confirm show mux status output reflects switchover. Signed-off-by: Lawrence Lee <[email protected]>
vmittal-msft
pushed a commit
to vmittal-msft/sonic-mgmt
that referenced
this pull request
Sep 28, 2021
What is the motivation for this PR? XCVRD runs some methods which attempt to read from cable hardware. This hardware doesn't exist for mux simulator, so XCVRD writes many errors to the syslog. How did you do it? Implement mocks for all methods in sonic_y_cable to prevent errors from being generated. How did you verify/test it? Inject new mux_simulator_client to dual ToR device with changes from sonic-net/sonic-platform-common#181. Verify PMON and mux containers stay up, and show mux status output looks normal. Initiate CLI switchover and confirm show mux status output reflects switchover. Signed-off-by: Lawrence Lee <[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]
Description of PR
Summary:
Fixes # (issue)
Type of change
Approach
What is the motivation for this PR?
XCVRD runs some methods which attempt to read from cable hardware. This hardware doesn't exist for mux simulator, so XCVRD writes many errors to the syslog.
How did you do it?
Implement mocks for all methods in
sonic_y_cableto prevent errors from being generated.How did you verify/test it?
Inject new mux_simulator_client to dual ToR device with changes from sonic-net/sonic-platform-common#181. Verify PMON and mux containers stay up, and
show mux statusoutput looks normal. Initiate CLI switchover and confirmshow mux statusoutput reflects switchover.Any platform specific information?
Supported testbed topology if it's a new test case?
Documentation