Karaf in OpenDaylight

[Thoughts] On Karaf & Its Future

These thoughts were originally sent on the public karaf-dev mailing list, where Robert Varga wrote a compelling opinion on what the future holds for Karaf and where its currently is headed. The text below was slightly edited from the original.

With my various OpenDaylight hats on, let me summarize our project-wide view, with a history going back to the project that was officially announced (early 2013).

From the get-go, our architectural requirement for OpenDaylight was OSGi compatibility. This means every single production (not maven-plugin obviously) artifact has to be a proper bundle.

This highly-technical and implementation-specific requirement was set down because of two things:

  1. What OSGi brings to MANIFEST.MF in terms of headers and intended wiring, incl. Private-Package
  2. Typical OSGi implementation (we inherited Equinox and are still using it) uses multiple class loaders and utterly breaks on split packages

This serves as an architectural requirement that translates to an unbreakable design requirement of how the code must be structured.

We started up with a home-brew OSGi container. We quickly replaced it for Karaf 3.0.x (6?), massively enjoying it being properly integrated, with shell, management, and all that. Also, feature:install.

At the end of the day, though, OpenDaylight is a toolkit of a bunch of components that you throw together and they work.

Our initial thinking was far removed from the current world of containers when operations go. The deployment was envisioned more like an NMS with a dedicated admin team (to paint a picture), providing a flexible platform.

The world has changed a lot, and the focus nowadays is on containers providing a single, hard-wired use-case.

We now provide out-of-the-box use-case wiring. using both dynamic Karaf and Guice (at least for one use case). We have an external project which shows the same can be done with pure Java, Spring Boot, and Quarkus.

We now also require Java 11, hence we have JPMS – and it can fulfill our architectural requirement just as well as OSGi. Thanks to OSGi, we have zero split packages.

We do not expect to ditch Karaf anytime soon, but rather leverage static-framework for a light-weight OSGi environment, as that is clearly the best option for us short-to-medium term, and definitely something we will continue supporting for the foreseeable future.

The shift to nimble single-purpose wirings is not going away and hence we will be expanding there anyway.

To achieve that, we will not be looking for a framework-of-frameworks, we will do that through native integration ourselves.

If Karaf can do the same, i.e. have its general-purpose pieces available as components, easily thrown together with @Singletons or @Components, with multiple frameworks, as well as nicely jlinkable – now that would be something. 

[OpenDaylight] Sodium: A Developers Perspective

by Robert Varga | Leave us your feedback on this post!

PANTHEON.tech continued to be the leader in terms of contributions to the OpenDaylight codebase. While our focus remained on the core platform, we also dabbled into individual plugins to deliver significant performance, scalability and correctness improvements. We are therefore glad to be a significant part of the effort that went into the newest release of OpenDaylight – Sodium.

In Sodium, we have successfully transitioned OpenDaylight codebase to require Java 11 – an effort we have been spearheading since the mid-Neon timeframe. This allows our users to not only reap the runtime improvements of Java 11 (which was possible to do with Sodium), but it allows OpenDaylight code to take advantage of features available in Java 11.

Our continued stewardship of YANG Tools has seen us deliver multiple improvements and new features, most notable of which are:

YANG Parser: has been extended to support Errata 5617 leaf-ref path expressions, which violate RFC7950, but are used by various models seen in the wild — such as ETSI NFV models. YANG parser has also received some improvements in areas of CPU and memory usage when faced with large models, ranging from 10 to 25%, depending on the models and features used.

In-memory Data Tree: the technology underlying most datastore implementations. It has been improved in multiple areas, yielding an overall memory footprint reduction of 30%. This allows better out-of-the-box scalability.

Adoption of Java 11: Java has allowed PANTHEON.tech to deploy improvements to MD-SAL Binding runtime, resulting in measurably faster dispatch of methods across the system, providing benefits to all OpenDaylight plugin code.

We have also continued improvements in the Distributed Datastore. We achieved further improvements to the persistence format, reducing in-memory & on-disk footprint by as much as 25%.

Last but not least, we have taken a hard look at the OVSDB project and provided major refactors of the codebase. This has immensely improved its ability to scale the number of connected devices, as well as individual connection throughput.

If you would like a custom OpenDaylight integration, feel free to contact us!

OpenDaylight Neon logo

[Comparison] OpenDaylight Neon SR1 vs. SR2

The development of OpenDaylight Sodium is already producing significant improvements, some of which are finding their way to the upcoming Service Release of Neon.

These are the test results for OpenDaylight Neon SR2. We have recorded significant improvements in the following areas:

  • Datastore snapshot-size: ~49% reduction
  • Processing time: ~58% reduction
  • In-memory size: ~25% reduction
  • Object count: ~25% reduction
  • NodeIdentifier: ~99.9% reduction
  • AugmentationIdentifier: ~99.9% reduction

These enhancements will also be present in the future, long-awaited release of Sodium.

Our commitment – more commits

PANTHEON.tech’s CTO, Robert Varga, is currently the top-single committer to OpenDaylights source-code, according to recent reports. PANTHEON.tech also resides as the number 1 contributor to its source-code.

Bitergia, a software development analytics company, regularly tracks the number of commits to OpenDaylight – based on single commiters and companies. OpenDaylight plays a significant role in PANTHEON.tech’s offerings and solutions.

Apart from PANTHEON.tech’s position as a top contributing organization to ODL, PANTHEON.tech has always been a strong supporter of the open-source community. This support covers a wide range of developers from local, private open-source development groups to international open-source platforms – such as ONAP, OPNFV or FD.io.

What is OpenDaylight?

OpenDaylight is a collaborative, open-source project, established in 2013. It aims to speed up the adoption of SDN and create a solid foundation for Network Functions Virtualization.

It was founded by global industry leaders, such as Cisco, Ericsson, Intel, IBM, Dell, HP, Red Hat, Microsoft, PANTHEON.tech and open to all.

PANTHEON.tech’s involvement in OpenDaylight goes way back to its beginnings. We have led the way in what an SDN controller is and should aspire to be. This requires dedication, which was proven over the years with an extensive amount of contribution and a successful track record, thanks to our expert developers.

Contact us, if you are interested in our solutions, which are based on, or integrate OpenDaylights framework.

OpenDaylight Sodium logo

[Release] OpenDaylight Sodium, YANG Tools & MD-SAL

It is no secret, that OpenDaylight is more than a passion project here at PANTHEON.tech. As one of the staples in the SDN revolution, we are also proud that we are one of the largest contributors to the project, with our PANTHEON.tech Fellow Robert Varga leading in the number of individual commits. Let us have a look at what is new.

YANG Tools 3.0.0

YANG Tools is a set of libraries and data modeling language, used to model state & configuration data. It’s libraries provide support for NETCONF and YANG for Java-based projects and applications.  What’s new in the world of the latest Yangtools release?

It implements new RFCs: RFC7952 (Defining and Using Metadata with YANG) and RFC8528 (YANG Schema Mount).

YANG parser now supports RFC6241 & RFC8528, while adding strict QName rules for “node identifiers”.

JDK11 support has been added together with lots of small bugfixes, which you can read in detail in its changelog.

MD-SAL 4.0.0

The Model-Driven Service Abstraction Layer is OpenDaylight’s kernel – it interfaces between different layers and modules. MD-SAL uses APIs to connect & bind requests and services and delegates certain types of requests.

The new version of MD-SAL has been released for ODL. MD-SAL is one of the central OpenDaylight components. This release contains mainly bugfixes and brings pre-packaged model updates for newly released IETF  models: RFC8519, RFC8528, RFC8529, RFC8530.

OpenDaylight Release Sequence

Get ready for OpenDaylight Sodium

OpenDaylights development has a new important milestone ahead: the Sodium release, currently scheduled around September 2019. This release will bring new versions of YANG Tools, MD-SAL and other core OpenDaylight components.

JDK11, as well as JKD8, is supported, providing an opportunity for OpenDaylight users to try new features of JDK11. It bids farewell to Java EE modules & JavaFX, as well as performance & bug fixes.

We believe you are also looking forward to these releases and encourage you to try them out!

Don’t forget to contact us, in case you are interested in a commercial solution for your business!

You can contact us at https://pantheon.tech/

Explore our Pantheon GitHub.

Watch our YouTube Channel.

PANTHEON.tech & OpenDaylight

PANTHEON.tech is the 2nd largest OpenDaylight contributor for Q3/2018

In the last week of November 2018, Bitergia, a software development analytics company, published a report on the past and current status of the OpenDaylight project, which plays a significant role in PANTHEON.tech’s offerings and solutions.

PANTHEON.tech’s CTO Robert Varga, is leading the list of per-user-contributions to the source code of OpenDaylight, with over 980 commits to the source code in Q3 of 2018. This achievement further establishes PANTHEON.tech’s position as one of the largest contributors to the OpenDaylight project.

As for the list of companies which contribute to the source code of OpenDaylight, PANTHEON.tech is the 2nd largest contributor for Q3/2018, with 1034 commits. We were just 34 commits shy of the top contributor position, which belongs to Red Hat.

Due to ODL’s open-source nature, anyone can contribute to the project and improve it in the long-run. Any change that gets added to the source code is defined as a commit. These types of changes need an approval and can not be any type of automated activity – including bot-actions or merges. This means, that each single commit is a unique change, added to the source code.

PANTHEON.tech will continue its commitment to improving OpenDaylight and we are looking forward to being a part of the future of this project.

What is OpenDaylight?

ODL is a collaborative open source project aimed to speed up the adoption of SDN and create a solid foundation for Network Functions Virtualization (NFV).

PANTHEON.tech’s nurture for ODL goes back when it was forming. In a sense, PANTHEON.tech has led the way is and how an SDN controller is and should be. This requires dedication, which was proven over the years with the extensive amount of contribution thanks to its expert developers.

Click here if you are interested in our solutions, which are based on, or integrate ODL’s framework.

You can contact us at https://pantheon.tech/

Explore our Pantheon GitHub.

Watch our YouTube Channel.