Description
sonic-telemetry_client.yang defines a Table level container with one container Global for static key(This is fine), but it also has two lists TELEMETRY_CLIENT_DS_LIST and TELEMETRY_CLIENT_SUB_LIST with same key count, this pattern is not recommended. As per the guideline we can only split the tables with lists with distinct number of keys (not with pattern and type).
Even sonic-utilities is failing to apply the configs.
Steps to reproduce the issue:
- Create JsonPatch. Sample JsonPatch:
[{"op": "add", "path": "/TELEMETRY_CLIENT/Subscription_A/paths", "value": "xyz"}]
- Using GCU with JsonPatch above
admin@sonic:~$ sudo config apply-patch -v ./p5.json
Patch Applier: Patch application starting.
Patch Applier: Patch: [{"op": "add", "path": "/TELEMETRY_CLIENT/Subscription_A/paths", "value": "[192.168.1.1:8080](http://192.168.1.1:8080/)"}]
Patch Applier: Getting current config db.
Patch Applier: Simulating the target full config after applying the patch.
Patch Applier: Validating all JsonPatch operations are permitted on the specified fields
Patch Applier: Validating target config does not have empty tables, since they do not show up in ConfigDb.
Patch Applier: Sorting patch updates.
Patch Sorter - Strict: Validating patch is not making changes to tables without YANG models.
libyang[1]: Default value "" in the list key "port" is ignored. (/sonic-snmp:sonic-snmp/SNMP_AGENT_ADDRESS_CONFIG/SNMP_AGENT_ADDRESS_LIST)
libyang[1]: Default value "" in the list key "vrf_name" is ignored. (/sonic-snmp:sonic-snmp/SNMP_AGENT_ADDRESS_CONFIG/SNMP_AGENT_ADDRESS_LIST)
Patch Sorter - Strict: Validating target config according to YANG models.
Patch Sorter - Strict: Sorting patch updates.
Failed to apply patch
Usage: config apply-patch [OPTIONS] PATCH_FILE_PATH
Try "config apply-patch -h" for help.
Error: Path token not found.
model: OrderedDict([('@name', 'TELEMETRY_CLIENT_DS_LIST'), ('key', OrderedDict([('@value', 'prefix')])), ('ordered-by', OrderedDict([('@value', 'user')])), ('leaf', [OrderedDict([('@name', 'prefix'), ('type', OrderedDict([('@name', 'string'), ('pattern', OrderedDict([('@value', 'DestinationGroup_.*')]))])), ('__isleafList', False)]), OrderedDict([('@name', 'dst_addr'), ('type', OrderedDict([('@name', 'ipv4-port')])), ('__isleafList', False)])])])
token_index: 2
path_tokens: ['TELEMETRY_CLIENT', 'Subscription_A', 'paths']
config: {'report_interval': '200', 'paths': 'xyz'}
Describe the results you received:
Failed application of JsonPatch, unable to write the configs
Describe the results you expected:
Successful application of JsonPatch
Additional Information
The SONiC YANG guideline currently lacks specific rules concerning multiple LIST elements within a table-level container. At present, sonic-utility selects the first LIST found within such a container. This approach works correctly only when the number of keys for each LIST differs, as seen in sonic-interface. However, it fails when the LISTs have the same number of keys, as is the case in sonic-telemetry_client.yang.
To safeguard against future application issues, I've updated the guideline to include a new point specifically addressing TABLE keys when the content is divided into multiple lists. The changes are available in this PR.
Description
sonic-telemetry_client.yang defines a Table level container with one container Global for static key(This is fine), but it also has two lists TELEMETRY_CLIENT_DS_LIST and TELEMETRY_CLIENT_SUB_LIST with same key count, this pattern is not recommended. As per the guideline we can only split the tables with lists with distinct number of keys (not with pattern and type).
Even sonic-utilities is failing to apply the configs.
Steps to reproduce the issue:
[{"op": "add", "path": "/TELEMETRY_CLIENT/Subscription_A/paths", "value": "xyz"}]Describe the results you received:
Failed application of JsonPatch, unable to write the configs
Describe the results you expected:
Successful application of JsonPatch
Additional Information
The SONiC YANG guideline currently lacks specific rules concerning multiple LIST elements within a table-level container. At present, sonic-utility selects the first LIST found within such a container. This approach works correctly only when the number of keys for each LIST differs, as seen in sonic-interface. However, it fails when the LISTs have the same number of keys, as is the case in sonic-telemetry_client.yang.
To safeguard against future application issues, I've updated the guideline to include a new point specifically addressing TABLE keys when the content is divided into multiple lists. The changes are available in this PR.