OpenDaylight ‘s distribution package remained the same for several years. But what if there is a different way to do this, making distribution more aligned with the latest containerization trends? This is where an OpenDaylight Static Distribution comes to the rescue.
Original Distribution & Containerized Deployments
Let’s take a quick look at the usual way.
A standard distribution is made up of:
- a pre-configured Apache Karaf
- a full set of OpenDaylight’s bundles (modules)
It’s an excellent strategy for when the user wants to choose modules and build his application dynamically from construction blocks. Additionally, Karaf provides a set of tools that can affect configuration and features in runtime.
However, when it comes to micro-services and containerized deployments, this approach confronts some best practices for operating containers — statelessness and immutability.
Perks of a Static Distribution
Starting from version 4.2.x, Apache Karaf provides the capability to build a static distribution, aiming to be more compatible with the containerized environment — and OpenDaylight can use that as well.
So, what are the differences between a static vs. dynamic distribution?
Instead of adding everything to the distribution, you only need to specify a minimal list of features and required bundles in your runtime, so only they will be installed. This would help produce a lightweight distribution package and omit unnecessary stuff, including some Karaf features from the default distribution.
Boot features are pre-configured, no need to execute any feature installations from Karaf’s shell.
Configuration admin is replaced with a read-only version that only picks up configuration files from the ‘/etc/’ folder.
Bundle dependencies are resolved and verified during the build phase, which leads to more stable builds overall.
With all these changes in place, we can achieve an almost entirely immutable distribution, which can be used for the containerized deployments.
Now, we can produce immutable & lightweight OpenDaylight distributions with a selected number of pre-installed features, which can be the first step to create Docker images that would be fully compliant for the containerized deployment.
Our next steps would be to make logging and clustered configuration more suitable for running in containers, but that’s a topic for another article.
Originally published at https://pantheon.tech on February 15, 2021.