Skip to content

[action] [PR:12503] Put back #11934, fix qos/test_qos_sai.py teardown for dualtor.#12862

Merged
mssonicbld merged 1 commit intosonic-net:202311from
mssonicbld:cherry/202311/12503
May 16, 2024
Merged

[action] [PR:12503] Put back #11934, fix qos/test_qos_sai.py teardown for dualtor.#12862
mssonicbld merged 1 commit intosonic-net:202311from
mssonicbld:cherry/202311/12503

Conversation

@mssonicbld
Copy link
Collaborator

This reverts commit 616df5f.

Description of PR

Summary: Fix qos/tes_qos_sai.py teardown failure for dualtor.
Fixes #78

Type of change

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

Back port request

  • 201911
  • 202012
  • 202205
  • 202305
  • 202311

Approach

What is the motivation for this PR?

qos/test_qos_sai.py fails at teardown

failed on setup with "Failed: All critical services should be fully started!

Regression introduced by #10651 for dualtor.

How did you do it?

The config_reload in the fixture dut_disable_ipv6 waits until all critical processes are up after issuing config reload command and it timeouts in case of dualtor because mux container doesn't come up. Mux container is disabled by another fixture stopServices in the same file. These two fixtures have no dependency on each other hence the execution can happen in any order, so if the teardown of dut_disable_ipv6 happens before stopServices then this issue is seen.

This change ensures that the teardown of stopServices happens before dut_disable_ipv6 so that mux is no longer disabled at the time of config_reload.

How did you verify/test it?

Ran qos/test_qos_sai.py on Arista-7260CX3 platform with dualtor topology with 202305 and 202311 images.

Any platform specific information?

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

Documentation

…r. (sonic-net#12503)

What is the motivation for this PR?
qos/test_qos_sai.py fails at teardown

failed on setup with "Failed: All critical services should be fully started!
Regression introduced by sonic-net#10651 for dualtor.

How did you do it?
The config_reload in the fixture dut_disable_ipv6 waits until all critical processes are up after issuing config reload command and it timeouts in case of dualtor because mux container doesn't come up. Mux container is disabled by another fixture stopServices in the same file. These two fixtures have no dependency on each other hence the execution can happen in any order, so if the teardown of dut_disable_ipv6 happens before stopServices then this issue is seen.

This change ensures that the teardown of stopServices happens before dut_disable_ipv6 so that mux is no longer disabled at the time of config_reload.

How did you verify/test it?
Ran qos/test_qos_sai.py on Arista-7260CX3 platform with dualtor topology with 202305 and 202311 images.
@mssonicbld
Copy link
Collaborator Author

Original PR: #12503

@mssonicbld mssonicbld merged commit 682532c into sonic-net:202311 May 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants