OpenDaylight’s YANG Tools project, nick-named yangtools, forms the bottom-most layer of OpenDaylight as an application platform. It defines and implements interfaces for modeling, storing and transforming data modeled in RFC7950, a.k.a. YANG 1.1 — such as a YANG parser and compiler.
Pantheon engineers started yangtools some 5 years ago, originally supporting RFC6020, going through a number of verions, before finally releasing yangtools-1.0.0 and with it semantic versioning as an API contract. Since then we have retrofitted original RFC6020 metamodel to support RFC7950 and implemented the corresponding parser bits, which were finalized in yangtools-1.2.0, hich shipped with Nitrogen Simultaneous Release.
This release entered its development phase on August 14, 2017 and yangtools-2.0.0 was released on November 27, 2017, which is when the search of an integration window started. Eventhough we had the most critical downstream integration patches prepared, most of downstreams did not have their patches even started. Integration work and coordination was quickly escalated to the TSC and the integration finally kicked off on January 11, 2018.
The integration was mostly complicated by the fact that odlparent-3.0.x was riding with us, along with the usual Karaf/Jetty/Jersey/Jackson integration mess, but it is now sorted out, with angtools-2.0.1 being the release to be shipped in Oxygen Simultanenous Release.
So what is new in yangtools-2.0.1?
Quite a lot based on code movement statistics:
– 309 commits
– 2009 files changed
– 54126 insertions(+), 45014 deletions(-)
Which is not that surprising, given that 2.0.0 gave us the opportunity to break APIs in 18 months. That does not really tell the story, though, so here is a run-down of what lies behind those numbers.
The most user-visible change is that in-memory data tree now enforces mandatory leaf node presence for operational store by default. This can be tweaked via the DataTreeConfiguration interface on a per-instance basis, if need be, but we recommend against switching it off.
For downstream users using karaf packaging, we have split our features into stable and experimental ones. Stable features are available from features-yangtools and contain the usual set of functionality, which will only expand in its capabilities. Experimental features are available from features-yangtools-experimental and carry functionality which is not stabilized yet and may get removed — this currently includes ObjectCache, which is slated for removal, as Guava’s Interners are better suited for the job.
Users of yang-maven-plugin will find that YANG files packaged in jars now have their names normalized to RFC7950 guidelines. This includes using the actual module or submodule name as well as capturing the revision in the filename.
From API change perspective, there are two changes which stand out. We have pruned all deprecated methods and all YANG 1.1 API hacks marked with ‘FIXME: 2.0.0’ have been cleared up. This results in better ergonomics for both API users and implementors.
yang-model-api has seen some incompatible changes, ranging from renaming of AugmentationNode, TypedSchemaNode and ChoiceCaseNode to some targetted use of Optional instead of nullable returns. Most significant change here is the introduction of EffectiveStatement specializations — I will cover these in detail in a follow-up post, but these have enabled us to do the next significant item.
YANG parser has been refactored into multiple components and its internal structure changed to hide most of the implementation classes and methods. It is now split into yang-parser-reactor language-independent inference pipeline), yang-parser-rfc7950 (hosting baseline RFC6020/RFC7950 parser), yang-parser-impl (being the default-configured parser instance) and a slew of parser extensions (RFC6536, RFC7952, RFC8040). There is a yang-parser-spi artifact, too, which hosts common namespaces and utility classes, but its layout is far from stabilized. Overall the parser has become a lot more efficient, better at detecting and reporting model issues and implementing new semantic extensions has become really a breeze.
YANG codecs have seen a major shift, with the old XML parser in yang-data-impl removed in favor of yang-data-codec-xml and yang-data-codec-gson gaining the ability to parse and emit RFC7951 documents — allowing RFC8040 NETCONF module to come closer to full compliance. Since the SchemaContext is much more usable now, with Modules being indexed by their NameModule, the codec operations have become significantly faster.
Overall we are in a much better and cleaner shape. We are currently not looking at a 3.0.0 release anytime soon and can actually deliver incremental improvements to YANG Tools in a much more rapid cadence than previously possible with the entire OpenDaylight simultaneous release cycle being in the way.
We already have another round of changes nearly ready for yangtools-2.0.2, watch this space for an update around that next week.