Fix fixture invocation order in qos/qos_sai_base.py#12152
Merged
StormLiangMS merged 2 commits intosonic-net:masterfrom Apr 18, 2024
Merged
Fix fixture invocation order in qos/qos_sai_base.py#12152StormLiangMS merged 2 commits intosonic-net:masterfrom
StormLiangMS merged 2 commits intosonic-net:masterfrom
Conversation
8 tasks
Collaborator
|
hi @neethajohn @XuChen-MSFT could you help to review? |
neethajohn
approved these changes
Apr 17, 2024
Contributor
|
@XuChen-MSFT , please take a look |
Collaborator
|
hi @vivekverma-arista could you run test with 202311 image? |
8 tasks
Contributor
Author
Hi @StormLiangMS |
mssonicbld
pushed a commit
to mssonicbld/sonic-mgmt
that referenced
this pull request
Apr 26, 2024
What is the motivation for this PR? qos/test_qos_sai.py fail with the following - failed on setup with "Failed: Not all critical processes are healthy" The fixture dut_disable_ipv6 disables ipv6 due to which the following critical processes don't come up after swapping syncd ( fixture swapSyncd_on_selected_duts ) - program:snmpd program:snmp-subagent And this issue only hits if swapSyncd_on_selected_duts is executed after dut_disable_ipv6 and since there is no dependency between these fixtures, they can execute in any order. How did you do it? This change introduces a dependency between dut_disable_ipv6 & swapSyncd_on_selected_duts such that former is always executed after latter. How did you verify/test it? Tested on Arista-7050CX3 platform with dualtor topology.
Collaborator
|
Cherry-pick PR to 202311: #12596 |
8 tasks
mssonicbld
pushed a commit
that referenced
this pull request
Apr 26, 2024
What is the motivation for this PR? qos/test_qos_sai.py fail with the following - failed on setup with "Failed: Not all critical processes are healthy" The fixture dut_disable_ipv6 disables ipv6 due to which the following critical processes don't come up after swapping syncd ( fixture swapSyncd_on_selected_duts ) - program:snmpd program:snmp-subagent And this issue only hits if swapSyncd_on_selected_duts is executed after dut_disable_ipv6 and since there is no dependency between these fixtures, they can execute in any order. How did you do it? This change introduces a dependency between dut_disable_ipv6 & swapSyncd_on_selected_duts such that former is always executed after latter. How did you verify/test it? Tested on Arista-7050CX3 platform with dualtor topology.
mssonicbld
pushed a commit
to mssonicbld/sonic-mgmt
that referenced
this pull request
Sep 14, 2024
What is the motivation for this PR? qos/test_qos_sai.py fail with the following - failed on setup with "Failed: Not all critical processes are healthy" The fixture dut_disable_ipv6 disables ipv6 due to which the following critical processes don't come up after swapping syncd ( fixture swapSyncd_on_selected_duts ) - program:snmpd program:snmp-subagent And this issue only hits if swapSyncd_on_selected_duts is executed after dut_disable_ipv6 and since there is no dependency between these fixtures, they can execute in any order. How did you do it? This change introduces a dependency between dut_disable_ipv6 & swapSyncd_on_selected_duts such that former is always executed after latter. How did you verify/test it? Tested on Arista-7050CX3 platform with dualtor topology.
Collaborator
|
Cherry-pick PR to 202305: #14587 |
8 tasks
mssonicbld
pushed a commit
that referenced
this pull request
Sep 14, 2024
What is the motivation for this PR? qos/test_qos_sai.py fail with the following - failed on setup with "Failed: Not all critical processes are healthy" The fixture dut_disable_ipv6 disables ipv6 due to which the following critical processes don't come up after swapping syncd ( fixture swapSyncd_on_selected_duts ) - program:snmpd program:snmp-subagent And this issue only hits if swapSyncd_on_selected_duts is executed after dut_disable_ipv6 and since there is no dependency between these fixtures, they can execute in any order. How did you do it? This change introduces a dependency between dut_disable_ipv6 & swapSyncd_on_selected_duts such that former is always executed after latter. How did you verify/test it? Tested on Arista-7050CX3 platform with dualtor topology.
This file contains hidden or 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
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.
Description of PR
Summary: Fix fixture invocation order in qos/qos_sai_base.py
Fixes # (issue)
Type of change
Back port request
Approach
What is the motivation for this PR?
qos/test_qos_sai.py fail with the following -
The fixture
dut_disable_ipv6disables ipv6 due to which the following critical processes don't come up after swapping syncd ( fixtureswapSyncd_on_selected_duts) -And this issue only hits if
swapSyncd_on_selected_dutsis executed after dut_disable_ipv6 and since there is no dependency between these fixtures, they can execute in any order.How did you do it?
This change introduces a dependency between
dut_disable_ipv6&swapSyncd_on_selected_dutssuch that former is always executed after latter.How did you verify/test it?
Tested on Arista-7050CX3 platform with dualtor topology.
Any platform specific information?
Supported testbed topology if it's a new test case?
Documentation