-
Bug
-
Resolution: Duplicate
-
Medium
-
None
-
8.0.3
-
None
-
None
We are working on a PON project and just upgraded to Lighty 16.0.0 which uses :
YangTools version 8.0.3, NETCONF 3.0.2, MDSAL 9.0.2
We have a PON netconf device using bbf-l2-forwarding YANG models as well as bbf-sub-interface-tagging yang models.
After the device mounts to ODL, the swagger for the mounted device cannot be generated. ODL prints errors such as:
2022-07-13T17:37:32.454 [${env:APP_NAME}] [${env:APP_VERSION}] WARN pondc CommScope [] [${env:NODE_NAME}] qtp1770701191-199 [] HttpChannel.handleException - /apidoc/openapi3/18/apis/mounts/6
javax.servlet.ServletException: java.lang.IllegalArgumentException: Schema tree child (urn:bbf:yang:bbf-l2-forwarding?revision=2020-10-13)mac-address-value not present in schema parent (urn:bbf:yang:bbf-l2-forwarding?revision=2020-10-13)mac-address
at org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:432) ~[jersey-container-servlet-core-2.27.jar:?]
at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:370) ~[jersey-container-servlet-core-2.27.jar:?]
One problem that seems to be recurring is that the “choice” fields in the yang models are named something X, and underneath the choice there could be a leaf/container/case named the same thing.
I think this is confusing ODL’s yang tool parser?
Examples:
1) bbf-l2-forwarding-forwarding-databases@2020-10-13.yang
A yang model has a case statement like this.. and then has a choice under it with the same name as the case..
ODL doesn’t like this at all. If I change the name of the choice to allow-to-learn-on-choice.. it accepts this syntax.
case allowed-to-learn-on {
if-feature "mac-learning";
choice allowed-to-learn-on { // Same as the case statement.. ODL doesn’t like it. If I change this name to something else, ODL is happy.
description
"The source MAC address of the frame can be learned
on any of the ports or interfaces as identified
further.";
2) bbf-frame-classification@2021-06-02
Here we have a choice statement called “mac-address” and then inside that choice statement we have a leaf defining a mac-address as well. ODL cannot handle this.
grouping mac-address-match {
description
"Provides a set of leafs that allow to classify a MAC address.";
choice mac-address { // take note of this..
case mac-address-filter {
description
"The value and the mask together identify a set of MAC
addresses that comply with this classification. Evaluation
is performed by making a bit-wise AND operation between the
to be evaluated MAC address and the mac-address-mask. There
is a match if the result equals the value specified in the
mac-address-value.";
leaf mac-address-value {
type yang:mac-address; // This seems valid to me. But choice is the same name.. I think that is illegal here.?
description "The value with which a comparison shall be made after performing the bit-wise AND operation on the to be evaluated MAC address.";
}
I have attached two tar files which contain minimal yang to recreate the issue.
1) l2-forwarding-yang.tar.gz - this can be fed into a NETCONF testtool simulator to reproduce the issue with l2-forwarding YANG models
2) sub-intf-tagging-yang.tar.gz - this contains the minimal amount of bbf-sub-interface-tagging yang to reproduce the issue for that yang. A NETCONF testtool simulator can be fed these to reproduce the issue on that yang.
I have also attached debug logs for each issue.
To reproduce create a NETCONF testtool simulator with one of the bunches of YANGs as the schema. Add to ODL, After the device connects/mounts, try to get to the swagger page for the device.
- duplicates
-
-
- Resolved
-
