[YANGTOOLS-1353] Yang models using "ietf-yang-schema-mount" mount-point are not supported in ODL Created: 19/Oct/21 Updated: 09/Feb/22 |
|
| Status: | Open |
| Project: | yangtools |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Medium |
| Reporter: | Robert Magaldi | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
| Description |
|
The Broadband Forum has a YANG 1.1 model called bbf-obbaa-network-manager.yang model which uses a "root" yang-schema-mount. That is, the "root" can point to any other YANG model. Example:
container network-manager {
description
"Infomations about the devices and adapters managed by BAA";
container managed-devices {
description
"The managed devices and device communication settings.";
list device {
key "name";
description
"The device list which managed by BAA.";
leaf name {
type string;
description
"The name of device.";
}
container device-management {
description
"The management informations for a device.";
uses management-grouping;
}
container device-notification {
description
"The notification triggered when the device state changed.";
uses notification-grouping;
}
container root {
yangmnt:mount-point "root";
description
"Root for models supported per device.";
}
}
}
...
In this yang model, there is a container called "root" which points to the root models of any yang model. The "yangmnt" is:
import ietf-yang-schema-mount {
prefix yangmnt;
}
Usage of this can be seen in the following notification - A system may have a "netconf-config-change" notification for example that has this "network-manager" yang underneath it: <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> <eventTime>2021-08-17T18:35:46+00:00</eventTime> <netconf-config-change xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-notifications"> <datastore>running</datastore> <changed-by> <username>PMA_USER</username> <session-id>1</session-id> <source-host>172.16.0.2</source-host> </changed-by> <edit> <target xmlns:baa-network-manager="urn:bbf:yang:obbaa:network-manager" xmlns:bbf-xpongemtcont="urn:bbf:yang:bbf-xpongemtcont">/baa-network-manager:network-manager/baa-network-manager:managed-devices/baa-network-manager:device[baa-network-manager:name='myDevice']/baa-network-manager:root/bbf-xpongemtcont:xpongemtcont/bbf-xpongemtcont:tconts/bbf-xpongemtcont:tcont[bbf-xpongemtcont:name='tcont_ont1_2_0']</target> <operation>create</operation> </edit> </netconf-config-change> </notification>
Is we look at the "target" part of the message above, we see that it is using the network manager yang, and also the bbf-xpongemtcont... /baa-network-manager:root/bbf-xpongemtcont:xpongemtcont/ The transition from "root" to an actual yang model (bbf-xpongemtcont) is not supported. ODL will throw away this notification because it cannot parse this. In the following file: XpathStringParsingPathArgumentBuilder(final AbstractStringInstanceIdentifierCodec codec, final String data) { this.codec = requireNonNull(codec); this.data = requireNonNull(data); this.current = codec.getDataContextTree().getRoot(); // RSM This line this.offset = 0; } The "getDataContextTree" will be relative to the "bbf-obba-network-manager" yang when parsing. When it comes time to find the "bbf-xpongemtcont" model, it will return null causing the notification to be thrown away as it does not exist in the context tree. Also, the yangtool issue here can be hacked to work allowing the notification up. But then there is a second issue where a notification listener for "netconf change notifications" will not get a proper JAVA object because of the "root schema mount". For example - org.opendaylight.mdsal.binding.dom.adapter.BindingDOMNotificationListenerAdapter (mdsal-binding-dom-adaptor version 7.0.6) @Override public void onNotification(final DOMNotification notification) { final Notification baNotification = deserialize(notification); final QName notificationQName = notification.getType().lastNodeIdentifier(); getInvoker(notification.getType()).invokeNotification(delegate, notificationQName, baNotification); } When the deserialize is complete, the baNotificaiton is not completely mapped to an object due to the "root" mount. More information can be added to this issue if required. Wondering if this is a known issue already related to YANG 1.1 and possibly part of 1.1 support in progress.
|
| Comments |
| Comment by Robert Varga [ 25/Oct/21 ] |
|
So YANG Schema Mount support is not thoroughly integrated in the stack, so depending on how the request is constructed, we may be losing some information we have. A secondary problem here is that a schema mount can mean two different things. Can you post the contents of /ietf-yang-schema-mount:schema-mounts operational datastore? |
| Comment by Robert Magaldi [ 01/Feb/22 ] |
|
Trying to clarify the issue... I believe there are no contents for the /ietf-yang-schema-mount:schema-mounts operational data store. We are not storing anything in this case. I think the issue is more general - I have attached a file "bbf-obba-network-manager@2021-02-01.yang". This is an Broadband forum network manager yang file which contains a "root" mount - meaning it points to any other yang model. Inside this yang for example there is this:
The issue is that "container root" is meant to point to any other YANG model. If a device "X" is mounted onto ODL, a controller talking to ODL could send a "bbf-network-manager" request through ODL to the mounted device. The YANG could have a "root" container which points to any other YANG model for example. This issue deals with notifications in particular - where a notification comes into ODL for a BBF NETCONF device and is pointing to another YANG model using the "root" container: BBF is using Yang 1.1 models, and this use of "root" to point to any other YANG model is the issue. |
| Comment by Robert Varga [ 01/Feb/22 ] |
|
Understood, but please note that in order to under stand what the device means when it says "baa-network-manager:root/" it must also populate the appropriate data in its operational datastore, as specified by RFC8528, specifically /schema-mounts/mount-points[module='baa-network-manager', label='root'. If it does not, the device is broken and there is nothing we can do simply because the device is violating the RFC and we have absolutely no idea how to interpret that mount-point instance. Without seeing the contents of that list entry, I cannot begin to speculate as to what to do with this issue. |
| Comment by Robert Magaldi [ 09/Feb/22 ] |
|
Sorry.. when I tried to get information I didn't have access to to a real device (simulator only). <schema-mounts xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount"> <module>network-manager</module> Guessing here.. This problem may be related to the yang tool file "XpathStringParsingPathArgumentBuilder.java" under yang/yang-data-util/src/main/java/org/opendaylight/yangtools... It seems when parsing a "root", ODL doesn't go back to its original list of schema context to see if it can figure it out. |