Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GCU portchannel interface test #4875

Merged
merged 3 commits into from
Jan 5, 2022
Merged

GCU portchannel interface test #4875

merged 3 commits into from
Jan 5, 2022

Conversation

wen587
Copy link
Contributor

@wen587 wen587 commented Dec 27, 2021

Description of PR

Summary: Testcase of portchannel interface for generic updater apply-patch
Fixes # (issue)

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?

End to End test support for Generic Updater apply-patch
This PR is to verify the usage of 'config apply-patch' works on portchannel interface

How did you do it?

First we setup clean portchannel interface env. Then make some config apply change. And check if the portchannel interfaces changed as expected.

How did you verify/test it?

Run test of sonic-mgmt/tests/generic_config_updater/test_portchannel_interface.py on KVM

Any platform specific information?

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

Documentation

@wen587 wen587 requested a review from a team as a code owner December 27, 2021 08:42
@wen587 wen587 requested a review from qiluo-msft December 27, 2021 08:44
# }

pytestmark = [
pytest.mark.topology('t0'),
Copy link
Contributor

@qiluo-msft qiluo-msft Dec 27, 2021

Choose a reason for hiding this comment

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

t0

also test on t1-lag? If you hardcoded some logic based on t0, is it possible to adapt to any topo? If not, we need to consider add test case sepately for t1-lag. #Pending

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Can you find me a t1-lag topo? I can check if the test can be adopted.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Maybe add t1-lag in another PR.
In this testcase, we are actually modifying the interface, like ip and attributes(mtu, min-link). Topo should not make any difference right?

output = apply_patch(duthost, json_data=json_patch, dest_file=tmpfile)
expect_op_success(duthost, output)

verify_attr_change(duthost, name, attr, value)
Copy link
Contributor

@qiluo-msft qiluo-msft Dec 27, 2021

Choose a reason for hiding this comment

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

verify_attr_change

For end-to-end test, we could also verify that teamd processes (per port channel) are running without crash. #Closed

Copy link
Contributor Author

Choose a reason for hiding this comment

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

How about checking portchannel pid?
docker exec -it teamd test -f /var/run/teamd/PortChannel0001.pid

Copy link
Contributor

Choose a reason for hiding this comment

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

Checking process such as command ps is better. There is risk that the process crashed but the pid file is still there.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Changed to state dump verification

@wen587 wen587 merged commit 5e1bb9a into sonic-net:master Jan 5, 2022
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.

2 participants