Re: MDSAL v2

Donald Hunter
 

Hi Mahesh,

I had some time available to look at this. The first thing I noted was that the pom file is using the config-parent and contains a lot of dependencies for implementation work. I changed it to use binding-parent 0.13.2 as the parent which I think was recommended for YANG model projects. I’m not sure what version of yangtools and mdsal was being used for code generation before, but this should ensure the right combination for stable/fluorine.

When I run mvn compile, I get the following error:

[WARNING] Argument "/rt:routing/rt:control-plane-protocols/rt:control-plane-protocol/bgp:bgp/bgp:interfaces/bgp:interface/bgp:name" is not valid XPath string at "/Users/donaldh/dev/MEF/unimgr/bgp/src/main/yang/ietf-bgp-common@...:277:10"
javax.xml.xpath.XPathExpressionException: com.sun.org.apache.xpath.internal.domapi.XPathStylesheetDOM3Exception: Prefix must resolve to a namespace: rt

Right enough, the import and rt prefix are missing from ietf-bgp-common so I added the import and now it compiles. This may be a problem with ODL yangtools and a YANG submodule that ‘belongs-to’ a module that does define the prefix. My guess is that’s a quirky corner of the spec.

Another thing worth noting is that you shouldn’t need to copy in all your YANG dependencies. They should be built as other ODL modules that you can reference. Some are available and some are missing. I found these:

    <dependency>
      <groupId>org.opendaylight.mdsal.binding.model.ietf</groupId>
      <artifactId>rfc8349-ietf-routing</artifactId>
    </dependency>
    <dependency>
      <groupId>org.opendaylight.mdsal.binding.model.ietf</groupId>
      <artifactId>rfc8294-ietf-routing-types</artifactId>
    </dependency>
    <dependency>
      <groupId>org.opendaylight.mdsal.model</groupId>
      <artifactId>iana-if-type-2014-05-08</artifactId>
    </dependency>
    <dependency>
      <groupId>org.opendaylight.mdsal.model</groupId>
      <artifactId>ietf-interfaces</artifactId>
    </dependency>

I tried building a project with the original ietf-bgp YANG modules and hit the same problem with relative paths that you saw. If I have time, I will see if I can debug the the code generator.

Cheers,
Donald.

On 23 Aug 2019, at 05:21, Mahesh Jethanandani <mjethanandani@...> wrote:

Hi Bartosz,

Here is the e-mail I had exchanged with Donald on the MDSAL/yangtools issue. It has been cross-posted on the unimgr list, so you will find details on the version of MDSAL I am using in that thread.

Also, since you mentioned yangtools, I dug out versions of the yangtools that are there. Let me know what you think, and if you have any questions.

And thanks for offering your help.


opendaylight-user@root>feature:list | grep yangtools
odl-yangtools-common                            | 1.2.0            |          | Started     | odl-yangtools-common                            | OpenDaylight :: Yangtools :: Common
odl-yangtools-yang-data                         | 1.2.0            |          | Started     | odl-yangtools-yang-data                         | OpenDaylight :: Yangtools :: Data Binding
odl-yangtools-yang-parser                       | 1.2.0            |          | Started     | odl-yangtools-yang-parser                       | OpenDaylight :: Yangtools :: YANG Parser
opendaylight-user@root>
Begin forwarded message:

From: Mahesh Jethanandani <mjethanandani@...>
Subject: Re: MDSAL v2
Date: August 8, 2019 at 10:35:31 AM PDT
To: Donald Hunter <donaldh@...>

Hi Donald,

Untar this tar ball at the root of your unimgr repository, and go into the bgp directory and run this command

mvn clean install -DskipTests

You should see this error:

[ERROR] yang-to-sources: Unable to generate sources with org.opendaylight.mdsal.binding.maven.api.gen.plugin.CodeGeneratorImpl generator
java.lang.ClassCastException: org.opendaylight.mdsal.binding.model.util.Types$ParametrizedTypeImpl cannot be cast to org.opendaylight.mdsal.binding.model.api.GeneratedTransferObject

Thanks.

On Thu, Aug 8, 2019 at 8:38 AM Mahesh Jethanandani <mjethanandani@...> wrote:
Hi Donald,

It is the latest draft of the BGP YANG model - https://tools.ietf.org/html/draft-ietf-idr-bgp-model-06

Let me send you a tar ball of all the models that are needed to compile the model. That would be easier than you trying to find them.

Cheers.

On Aug 8, 2019, at 3:14 AM, Donald Hunter (donaldh) <donaldh@...> wrote:

Hi Mahesh,

Can you share a link to the YANG module that is causing the issue?

Cheers,
Donald.

On 8 Aug 2019, at 01:54, Mahesh Jethanandani <mjethanandani@...> wrote:

Hi Donald,

See inline.

On Wed, Aug 7, 2019 at 2:42 AM Donald Hunter (donaldh) <donaldh@...> wrote:
Hi Mahesh,

Good question. When I build Unimgr fluorine/stable,  run karaf and check the bundle versions, it is using MDSAL version 2.5.2. This should be new enough for you. When I originally tried to do the neon migration work, neon was using MDSAL 3.0.x – I had to abandon that work because not all the  main Opendaylight components had been migrated to MDSA 3.0.x at the time. We could re-attempt that effort now against Neon-SR1.

Ok. Maybe before we decide which version to try to upgrade to, we should try to determine where this issues has been fixed.

A look at MDSAL issues addressed in stable Flourine can be found here. However, the bug I am encountering, which BTW was fixed in 2016, does not show up on the list. It could be that 

- It was fixed long time ago, and therefore not relevant to display.
- or it has not been rolled into the version of MDSAL that is on stable/flourine branch.

Is there a way to know whether a given version of MDSAL has a given fix?


Unimgr is currently aligned with Fluorine-SR2 and SR3 has been released so we could easily bump to MDSAL version 2.5.3 if you think that might help?

It would depend on whether that version has the fix for  MDSAL-159.


I cannot find a definitive list of what component versions are in what releases so I find it is easiest to download a given release, run it and then check what bundle versions it is running. This is possibly my biggest frustration with Opendaylight based projects – it is really hard to track which versions of all the Opendaylight components should be used for each named release. The only thing that does make sense is that Fluorine has atomic number 9 and it’s the 3rd service release, hence 0.9.3.

👹 

Cheers.


Cheers,
Donald.

On 6 Aug 2019, at 21:47, Mahesh Jethanandani <mjethanandani@...> wrote:

Hi Donald,

I ran into a bug in trying to convert YANG to Java in ODL. A look at Jira for ODL revealed the following bug  that has been fixed as part of MDSAL v2. However, I am not sure which version of mdsal is stable/flourine on, and is there a way to move to using mdsal v2 in that branch. If not, do we have to move to the later version, and if so, what?

You are the only person I know to ask questions around ODL. So sorry for throwing these questions at you. And thanks in advance.

Cheers.

Mahesh Jethanandani






--
Mahesh Jethanandani
mjethanandani@...


Mahesh Jethanandani





--
Mahesh Jethanandani
mjethanandani@...

<bgp.tar.gz>

Join unimgr-dev@lists.opendaylight.org to automatically receive all group messages.