How to support multiple revisions with same namespace

[asoka083]

Hi ,

I am using JNC in a java project where I need to connect to devices with different versions. One of the device supports "http://openconfig.net/yang/interfaces" with revision "2016-05-26" and another device supports "http://openconfig.net/yang/interfaces" with revision "2019-11-19" . Currently I see only one version we can enable for Yang Parser in JNC for a namespace. Hence what I can only do is use the latest revision and work . This will work most of time since in general yang models are backward compatible. But problem comes when some of the yang models are not backward compatible . In this I think JNC will map only known fields to YangElement. This will force to use Element class.

Can we have some some solution to this in JNC? something like we can keep the generated java for all revisions and provide a way to set the revision in YangElement ? - setPackage(String ns, String pkg, String revision) . And when we connect to device using capabilities it can be associated with respective packages. Anyone think this is doable thing ? Or any other suggestion ?

Thanks,
Ashok

[martin-volf]

Technically, not much if anything at all prevents you from generating two distinct sets of Java packages using the --jnc-output. Given that, you may be able to generate configuration trees based on one or the other package; and retrieving and parsing the configuration is kind of possible too when before getting the device configuration you run the enable() method of the right generated class.

But that is obviously not convenient and scalable, proper solution would require some refactoring around the YangElement and YangXMLParser classes, few local changes would hardly be enough.

[asoka083]

Agreed. We can generated 2 sets of java models and one by one we can enable and use it. But since enable() is static method and it sets the package for namespace globally we can use this to process 2 parallel requests involving two revisions.
For now looks like as mentioned refactoring YangElement and YangXMLParser is the option since I am sure vendors will not follow backward compatibility when we create new revisions . I hope Netconf/Yang also comes up with more stricter guidelines on versioning .