-
Bug
-
Resolution: Unresolved
-
Medium
-
None
-
None
-
None
-
None
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:
yang/yang-data-util/src/main/java/org/opendaylight/yangtools/yang/data/util/XpathStringParsingPathArgumentBuilder.java (yang tools 6.0.5)
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.
