With the release of Nitrogen, OpenDaylight continues to solidify itself as the de facto open networking controller standard. Although the release contains widespread enhancements and improvements, the main focus of the OpenDaylight Nitrogen release is the major version upgrade of the underlying Apache Karaf container from 3.0.8 to 4.0.9. Among other functions, Apache Karaf is used to coordinate ODL microservices and lifecycle, provide a common logging infrastructure, enable remote management through JMX and a unix-like shell, facilitate dynamic configuration and hot deployment, and provide a common set of base resources across the product. As such, Karaf has several responsibilities and has served as a crucial piece of infrastructure to the overall OpenDaylight architecture since its inclusion in the Helium release. It’s kind of a big deal ;)!
Since ODL Karaf dependency management is centralized in the odlparent project, an upgrade may initially seem trivial— just a one-liner version bump, right? Unfortunately, that is far from the case. As previously stated, each release of Karaf provides a set of common dependencies that should remain constant across applications in the container. This is done in order to centralize on a base set of hypothetically stable, interoperable and secure dependencies based on what is available from upstream projects at the time. Thus, even a minor version bump of the Karaf container version in odlparent can result in the need for a number of changes cascading across consuming projects in ODL— especially if Karaf’s upstream dependencies contain API changes.
Major versions of Apache Karaf, which often contain new features, dependencies, frameworks, and API changes, are arduous and expensive to consume. Moving to a new Karaf version becomes similar to transferring an existing building onto a new foundation; there will be some jagged pieces along the bottom that will need work to fit properly. With that said, it is critically important for ODL to keep current with Karaf releases in order to consume security fixes and avoid upstream dependency end-of-life scenarios. Centralization of common ODL dependencies in odlparent eases some of the heartburn associated with cross-project upgrades. Inclusion of the functionality to utilize version ranges in ODL, which continues to be developed, will ease upgrade woes in future releases. Additionally, a significant amount of testing infrastructure was added in the Nitrogen release timeframe to enhance runtime dependency resolution checks and identify problems earlier and more predictably.
Another noteworthy change which occurred in the Nitrogen timeframe is the decision of odlparent contributors to disaggregate the subproject release from the traditional simultaneous release plan. This means that odlparent now releases independently of the rest of ODL projects, and consuming projects depend on a released version rather than a snapshot. Snapshot artifacts are prone to change from day to day, which can cause nuisance to consumers. For example, imagine that a snippet of code compiles on Tuesday, and without any changes, fails to compile Wednesday morning. This problem is avoided by depending on released artifacts, as released artifacts should never change without a proper version bump. Consuming projects can treat the released odlparent artifacts as true upstream dependencies, and upgrades of those dependencies are now consumed with greater precision and control. Breaking odlparent out of the simultaneous release additionally allows the odlparent development team to continue to perform necessary upgrades of widely used core dependencies without breaking downstream projects, enabling a disaggregated and saner development workflow. Although odlparent is the only project to break off from the simultaneous release during the Nitrogen timeframe, contributors of other projects have expressed interest in following a similar plan in the near future. This is exciting for developers and users alike, as it assists in breaking down the traditionally monolithic release process of OpenDaylight into more manageable chunks.
Maturity of the platform and its community is recognized by the decision to invest in an infrastructure focused release. Focus is garnered around not only doing things, but doing them right. Upgrade of the Karaf version in ODL Nitrogen is a double-edged sword; the foundation of ODL is greatly improved but at the expense of requiring the sole focus of an entire, albeit shortened, release cycle to adapt to changes. The improvements weren’t free, but were necessary in order to continue to deliver a stable and secure platform. Fortunately for ODL application developers and consumers, several articles and code examples are available which provide assistance in transitioning to the updated ODL Nitrogen release. Additionally, the support lifecycle of the previous release, ODL Carbon, has been extended beyond the traditional lifespan in order to help ease transition woes.
If you’d like to learn more about the OpenDaylight Nitrogen Release, the ODL Foundation’s Nitrogen blog is available here: https://www.opendaylight.org/blog/2017/09/26/opendaylight-introduces-nitrogen. Dive in and download OpenDaylight’s Nitrogen release today from: https://www.opendaylight.org/downloads.
Written by Ryan Goulding, Principal Software Engineer at Inocybe Technologies.