Skip to content

Add tests for copp manager redesign#4891

Merged
wangxin merged 2 commits intosonic-net:masterfrom
JibinBao:copp_redsign_1
Jan 29, 2022
Merged

Add tests for copp manager redesign#4891
wangxin merged 2 commits intosonic-net:masterfrom
JibinBao:copp_redsign_1

Conversation

@JibinBao
Copy link
Contributor

@JibinBao JibinBao commented Jan 5, 2022

Description of PR

Add tests for CoPP Manager redesign feature

  1. CoPP Manger redesign test plan: Copp manager redesign test plan SONiC#903
  2. HLD: https://github.com/noaOrMlnx/sonic-swss/blob/4865a8eb37444c2c070ef49cc69690e4295ce07d/doc/copp_redisgn.md

Summary:
Fixes # (issue)
Dependency: Only when the PR below is merged, this PR can be merged
sonic-net/sonic-swss#2034

Type of change

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

Back port request

  • 201911

Approach

What is the motivation for this PR?

Add new tests for CoPP Redesign feature.

How did you do it?

Add new tests

How did you verify/test it?

Run New CoPP tests

Any platform specific information?

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

Documentation

@JibinBao JibinBao requested a review from a team as a code owner January 5, 2022 02:02
logger.info("Config save")
duthost.command("sudo config save -y")

reboot_type = random.choice(["cold", "fast", "warm", "soft"])
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@JibinBao is choosing a random type of reboot intended to verify behavior in case of any reboot type?
If the idea was to check this for all 4 types of reboots, I would suggest using test parametrization. Or as another option reboot type could be passed as command line argument using parser.adoption (similar to --send_rate_limit parameter). Any of these 2 approaches would be useful if we want to test a specific type of reboot.

Copy link
Contributor Author

@JibinBao JibinBao Jan 11, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @vcheketx ,
Because reboot consumes time very much, so we just want to choosing one randomly for one time.
When we run the test for multiple times, all reboot-type will be covered.
So we don't use test parametrization and parser.adoption.
thanks

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it doesn't work for one reboot type, then the test case would be flaky and cause trouble.
Can you add an option to cover all reboot types? If the option is not supplied, just use one fixed default reboot type.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or add an option for specifying reboot type as vscheketx suggested?

@JibinBao JibinBao removed the request for review from a team January 12, 2022 08:41
Add an option for specifing reboot type for copp reboot test, so make case result more stable
@liat-grozovik
Copy link
Collaborator

@wangxin could you please to review the fixes following your feedback?

@liat-grozovik liat-grozovik changed the title add tests for copp manager redesign Add tests for copp manager redesign Jan 27, 2022
@liat-grozovik
Copy link
Collaborator

@vcheketx any further comment or we can move forward and merge once the relevant code PR.
Please note the test plan PR as well.

@vcheketx
Copy link
Contributor

@vcheketx any further comment or we can move forward and merge once the relevant code PR. Please note the test plan PR as well.

@liat-grozovik @JibinBao no further comments, thanks for implementing option for specifying reboot type.

@wangxin wangxin merged commit 72d2a49 into sonic-net:master Jan 29, 2022
ZhaohuiS added a commit that referenced this pull request Feb 2, 2023
What is the motivation for this PR?
test_trap_config_save_after_reboot case should skipped in 202012 branch, since always_enable feature is not merged into 202012 image.
[CoPP] Add always_enabled field to coppmgr logic by noaOrMlnx · Pull Request #2034 · sonic-net/sonic-swss (github.com)

Test case was added in this PR:
#4891

xfail in this PR
[test] skip/xfail unmerged copp feature temporarily by yejianquan · Pull Request #5148 · sonic-net/sonic-mgmt (github.com)

How did you do it?
Xfail is not correct, it needs to be skipped for now.
Change xfail to skip.
Signed-off-by: Zhaohui Sun <[email protected]>
wangxin pushed a commit that referenced this pull request Feb 3, 2023
What is the motivation for this PR?
test_trap_config_save_after_reboot case should skipped in 202012 branch, since always_enable feature is not merged into 202012 image.
[CoPP] Add always_enabled field to coppmgr logic by noaOrMlnx · Pull Request #2034 · sonic-net/sonic-swss (github.com)

Test case was added in this PR:
#4891

xfail in this PR
[test] skip/xfail unmerged copp feature temporarily by yejianquan · Pull Request #5148 · sonic-net/sonic-mgmt (github.com)

How did you do it?
Xfail is not correct, it needs to be skipped for now.
Change xfail to skip.
Signed-off-by: Zhaohui Sun <[email protected]>
kellyyeh pushed a commit to kellyyeh/sonic-mgmt that referenced this pull request Mar 31, 2023
…7373)

What is the motivation for this PR?
test_trap_config_save_after_reboot case should skipped in 202012 branch, since always_enable feature is not merged into 202012 image.
[CoPP] Add always_enabled field to coppmgr logic by noaOrMlnx · Pull Request sonic-net#2034 · sonic-net/sonic-swss (github.com)

Test case was added in this PR:
sonic-net#4891

xfail in this PR
[test] skip/xfail unmerged copp feature temporarily by yejianquan · Pull Request sonic-net#5148 · sonic-net/sonic-mgmt (github.com)

How did you do it?
Xfail is not correct, it needs to be skipped for now.
Change xfail to skip.
Signed-off-by: Zhaohui Sun <[email protected]>
@Blueve
Copy link
Collaborator

Blueve commented Feb 22, 2024

Hi @JibinBao , why you not check has_trap or not in PolicyTest?
Are we expecting receives packets when trap has been removed?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants