[YANGTOOLS-1446] Some BBF Yang models have errors when generating swagger for mounted device Created: 13/Jul/22 Updated: 24/Oct/22 Resolved: 24/Oct/22 |
|
| Status: | Resolved |
| Project: | yangtools |
| Component/s: | None |
| Affects Version/s: | 8.0.3 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Medium |
| Reporter: | Robert Magaldi | Assignee: | Unassigned |
| Resolution: | Duplicate | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Description |
|
We are working on a PON project and just upgraded to Lighty 16.0.0 which uses : 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. Examples: 1) bbf-l2-forwarding-forwarding-databases@2020-10-13.yang 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. 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. |