Summary:
Fixes # (issue)
When updating config db, there are some invalid references modeled by yang model.
For example: ERR sonic_yang: Data Loading Failed:Leafref "/sonic-dhcp-server-ipv4:sonic-dhcp-server-ipv4/sonic-dhcp-server-ipv4:DHCP_SERVER_IPV4_RANGE/sonic-dhcp-server-ipv4:DHCP_SERVER_IPV4_RANGE_LIST/sonic-dhcp-server-ipv4:name" of value "range_192.168.0.91" points to a non-existing leaf.
Type of change
[ ] Bug fix
[ ] Testbed and Framework(new/improvement)
[x] Test case(new/improvement)
Back port request
[ ] 202012
[ ] 202205
[ ] 202305
[x] 202311
[x] 202405
Approach
What is the motivation for this PR?
When updating config db, there are some invalid references modeled by yang model.
we can adjust the order of applying patches to avoid invalid status.
How did you do it?
Adjust the order of config patches
How did you verify/test it?
Run tests
Any platform specific information?
Supported testbed topology if it's a new test case?
Description of PR
Summary: Fixes # (issue) When updating config db, there are some invalid references modeled by yang model.
For example: ERR sonic_yang: Data Loading Failed:Leafref "/sonic-dhcp-server-ipv4:sonic-dhcp-server-ipv4/sonic-dhcp-server-ipv4:DHCP_SERVER_IPV4_RANGE/sonic-dhcp-server-ipv4:DHCP_SERVER_IPV4_RANGE_LIST/sonic-dhcp-server-ipv4:name" of value "range_192.168.0.91" points to a non-existing leaf.
Type of change
Back port request
Approach
What is the motivation for this PR?
When updating config db, there are some invalid references modeled by yang model.
we can adjust the order of applying patches to avoid invalid status.
How did you do it?
Adjust the order of config patches
How did you verify/test it?
Run tests
Any platform specific information?
Supported testbed topology if it's a new test case?
Documentation