[YANGTOOLS-1446] Some BBF Yang models have errors when generating swagger for mounted device

Duplicate — Mon, 24 Oct 2022 20:08:45 +0000

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.

OpenDaylight JIRA

[YANGTOOLS-1446] Some BBF Yang models have errors when generating swagger for mounted device