[tests]: Fix test_MirrorDestMoveLag test failure#3639
[tests]: Fix test_MirrorDestMoveLag test failure#3639prsunny merged 6 commits intosonic-net:masterfrom
test_MirrorDestMoveLag test failure#3639Conversation
`test_MirrorDestMoveLag` performs the following steps: 1. Create mirror session 2. Enable non-LAG monitor port 3. Create LAG; move to LAG with one member 4. Remove LAG member 5. Create LAG member 6. Remove LAG; move to non-LAG 7. Disable non-LAG monitor port 8. Remove mirror session At Step3, we call `create_port_channel` and `set_interface_status` to create LAG and set admin_status "up". This creates a "PortChannel080" entry in the "PORTCHANNEL" table of CONFIG_DB, which results in the creation of a team device "PortChannel080" in Linux. When step 6 calls `remove_port_channel` to remove the LAG, it is expected that the "PortChannel080" entry created previously will be removed and the team device will be deleted. However, the current code does not remove the "PortChannel080" entry from CONFIG_DB and consequently the team device is not deleted. This issue causes a test failure. The reason is that subsequent tests try to create a "PortChannel080" and since the "PortChannel080" already exists, unexpected behavior occurs. This commit fixes the issue by changing the `remove_port_channel` code to delete the PortChannel entry. Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
liuh-80
left a comment
There was a problem hiding this comment.
Verified this PR can fix test case break caused by FRR upgrade.
@liuh-80 , why is this related to FRR upgrade? Can you provide more context? @dgsudharsan for viz |
Hi @prsunny , after FRR upgrade, sonic-swss PR blocked by that change, and after the fix FRR PR on sonic-buildimage repo merged, there still some failed test case, I verified this PR can fix the test_mirror.py issue: 2025-05-14T22:09:55.7744038Z -------- generated xml file: /agent/_work/1/s/tests/test_mirror_tr.xml --------- |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azpw run Azure.sonic-swss |
|
Only PR owner can use /azpw run |
|
/azp run Azure.sonic-swss |
|
Commenter does not have sufficient privileges for PR 3639 in repo sonic-net/sonic-swss |
|
@cscarpitta , you need trigger PR validation again, current test failed because build docker image with #850459 which does not contain the FRR fix. |
|
/azp run Azure.sonic-swss |
|
Commenter does not have sufficient privileges for PR 3639 in repo sonic-net/sonic-swss |
|
/azpw run Azure.sonic-swss |
|
/AzurePipelines run Azure.sonic-swss |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azpw run Azure.sonic-swss |
|
/AzurePipelines run Azure.sonic-swss |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azpw run Azure.sonic-swss |
|
/AzurePipelines run Azure.sonic-swss |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
@cscarpitta there are two more tests in test_mirror.py and 6 test cases in test_warm_reboot.py that are failing (These have been passing until May 9 and no swss changes have gone in since then that could have caused these failures). Could you please check if these are related to the FRR upgrades. I have temporarily skipped them in #3664 to let pipeline runs proceed. |
|
Hi @prabhataravind I’m already working on a different PR for the other test failures. In the meantime we can merge this PR to fix the |
This test (test_MirrorDestMoveLag) is currently skipped to unblock PRs. Could you remove the skip mark as part of this PR if you think this will pass? |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
Cherry-pick PR to 202505: #3700 |
* [tests]: Fix `test_MirrorDestMoveLag` test failure `test_MirrorDestMoveLag` performs the following steps: 1. Create mirror session 2. Enable non-LAG monitor port 3. Create LAG; move to LAG with one member 4. Remove LAG member 5. Create LAG member 6. Remove LAG; move to non-LAG 7. Disable non-LAG monitor port 8. Remove mirror session At Step3, we call `create_port_channel` and `set_interface_status` to create LAG and set admin_status "up". This creates a "PortChannel080" entry in the "PORTCHANNEL" table of CONFIG_DB, which results in the creation of a team device "PortChannel080" in Linux. When step 6 calls `remove_port_channel` to remove the LAG, it is expected that the "PortChannel080" entry created previously will be removed and the team device will be deleted. However, the current code does not remove the "PortChannel080" entry from CONFIG_DB and consequently the team device is not deleted. This issue causes a test failure. The reason is that subsequent tests try to create a "PortChannel080" and since the "PortChannel080" already exists, unexpected behavior occurs. This commit fixes the issue by changing the `remove_port_channel` code to delete the PortChannel entry.
|
Cherry-pick PR to 202411: #3804 |
* [tests]: Fix `test_MirrorDestMoveLag` test failure `test_MirrorDestMoveLag` performs the following steps: 1. Create mirror session 2. Enable non-LAG monitor port 3. Create LAG; move to LAG with one member 4. Remove LAG member 5. Create LAG member 6. Remove LAG; move to non-LAG 7. Disable non-LAG monitor port 8. Remove mirror session At Step3, we call `create_port_channel` and `set_interface_status` to create LAG and set admin_status "up". This creates a "PortChannel080" entry in the "PORTCHANNEL" table of CONFIG_DB, which results in the creation of a team device "PortChannel080" in Linux. When step 6 calls `remove_port_channel` to remove the LAG, it is expected that the "PortChannel080" entry created previously will be removed and the team device will be deleted. However, the current code does not remove the "PortChannel080" entry from CONFIG_DB and consequently the team device is not deleted. This issue causes a test failure. The reason is that subsequent tests try to create a "PortChannel080" and since the "PortChannel080" already exists, unexpected behavior occurs. This commit fixes the issue by changing the `remove_port_channel` code to delete the PortChannel entry.
* [tests]: Fix `test_MirrorDestMoveLag` test failure `test_MirrorDestMoveLag` performs the following steps: 1. Create mirror session 2. Enable non-LAG monitor port 3. Create LAG; move to LAG with one member 4. Remove LAG member 5. Create LAG member 6. Remove LAG; move to non-LAG 7. Disable non-LAG monitor port 8. Remove mirror session At Step3, we call `create_port_channel` and `set_interface_status` to create LAG and set admin_status "up". This creates a "PortChannel080" entry in the "PORTCHANNEL" table of CONFIG_DB, which results in the creation of a team device "PortChannel080" in Linux. When step 6 calls `remove_port_channel` to remove the LAG, it is expected that the "PortChannel080" entry created previously will be removed and the team device will be deleted. However, the current code does not remove the "PortChannel080" entry from CONFIG_DB and consequently the team device is not deleted. This issue causes a test failure. The reason is that subsequent tests try to create a "PortChannel080" and since the "PortChannel080" already exists, unexpected behavior occurs. This commit fixes the issue by changing the `remove_port_channel` code to delete the PortChannel entry. Signed-off-by: Baorong Liu <96146196+baorliu@users.noreply.github.com>
test_MirrorDestMoveLagperforms the following steps:At Step3, we call
create_port_channelandset_interface_statusto create LAG and set admin_status "up".This creates a "PortChannel080" entry in the "PORTCHANNEL" table of CONFIG_DB, which results in the creation of a team device "PortChannel080" in Linux.
When step 6 calls
remove_port_channelto remove the LAG, it is expected that the "PortChannel080" entry created previously will be removed and the team device will be deleted.However, the current code does not remove the "PortChannel080" entry from CONFIG_DB and consequently the team device is not deleted.
This issue causes a test failure. The reason is that subsequent tests try to create a "PortChannel080" and since the "PortChannel080" already exists, unexpected behavior occurs.
This PR fixes the issue by changing the
remove_port_channelcode to delete the PortChannel entry.