draft for dhcp server testcase#4485
Conversation
There was a problem hiding this comment.
There was a problem hiding this comment.
Also design for DHCPv6? It is a relative new feature, but we can still design for it.
There was a problem hiding this comment.
How about "1. reach maximal servers" ? Is there an maximal number by design or by implementation?
There was a problem hiding this comment.
Will ask see if there is the design
|
This pull request introduces 1 alert when merging afafa900a7a868f79351e46ddfae78e8e3f57012 into 66c554d - view on LGTM.com new alerts:
|
|
This pull request introduces 1 alert when merging d2573c2af20287f83e2c823465d2e00888ba1cd8 into 058a790 - view on LGTM.com new alerts:
|
|
This pull request introduces 1 alert when merging 4faac70e9f33b576182c395291ee3a4cdb54ad17 into 7f777f4 - view on LGTM.com new alerts:
|
|
This pull request introduces 1 alert when merging 6c4554c3eef2f8f20f0ccfb406c37a252fbb8c09 into 106b4bb - view on LGTM.com new alerts:
|
|
This pull request introduces 1 alert when merging 323eeacd9caef436785a3e27c6a6ed590245a257 into 8d65f7c - view on LGTM.com new alerts:
|
There was a problem hiding this comment.
Also applicable to other new functions in this file.
There was a problem hiding this comment.
No. It is restricted by utils_vlan_intfs_dict_add which in range(0, 255)
There was a problem hiding this comment.
Here I use magic number due that if the index change, the json will look much different. Here I choose to remove the last element for simplicity but also check the correctness. If I choose to remove other index such as 1. The json_patch will look like this:
[
{
"op": "remove",
"path": "/VLAN/Vlan108/dhcp_servers/3"
},
{
"op": "replace",
"path": "/VLAN/Vlan108/dhcp_servers/2",
"value": "192.0.108.4"
},
{
"op": "replace",
"path": "/VLAN/Vlan108/dhcp_servers/1",
"value": "192.0.108.3"
}
]
The vlan dhcp server is not simple key->value pair. It looks like a key->indexed value
2. Reuse code from vlan/test_vlan.py 3. resolve comment
…config updater(sonic-net#4485) Summary: Testcase of dhcp server under vlan for generic updater apply-patch Approach: What is the motivation for this PR? This is a requirement from E2E test support for Generic Updater apply-patch. This PR is to verify the usage of 'config apply-patch' works on dhcp server under vlan. How did you do it? First we setup vlan for test. Then make some config apply change. And check if the dhcp server is changed as expected. How did you verify/test it? Run test on sonic-mgmt/tests/generic_config_updater/test_dhcp_relay.py
Description of PR
Summary: Testcase of dhcp server for generic updater apply-patch
Fixes # (issue)
Type of change
Back port request
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 dhcp server under vlan.
How did you do it?
First we setup vlan for test. Then make some config apply change. And check if the dhcp server is changed as expected.
For code reusability, some vlan setup functions are moved to
tests/common/fixtures/duthost_utils.pyImplement a utility file
gu_utils.pyfor future other testcase.How did you verify/test it?
Run test on sonic-mgmt/tests/generic_config_updater/test_dhcp_relay.py
Any platform specific information?
Supported testbed topology if it's a new test case?
Documentation