OpenDaylight Maven and OSGI Dev Notes

OPENDAYLIGHT MAVEN AND OSGI DEV NOTES

Prior to OpenDaylight I had only used the ODGI framework with David Ericson’s Beacon contorller. I wanted to dump some of my notes from code hacking over the past couple of weeks. Most of the time has been spent getting used to OSGI and Maven. After the Maven and OSGI overviews, I list my dev notes for setting OSGI log levels, building an individual specific OpenDaylight bundle with Maven and making a creating a new module to hack on.

WHAT IS OSGI?

OSGI is adds a modular framework that allows for dynamic loading of Java modules. This means you can load and unload , start and stop applications without taking down the running JVM platform. This seems to fits the theme of OpenDaylight to allow applications and protocols to plug into the framework to fit different use cases and vendor strategies. The platform is merely a series of Java interfaces. The projects that plug into the framework are referred to as bundles. The bundles need a few things to get started.

WHAT IS MAVEN?

Here are some high points of the value Maven brings. Maven is awesome becuase it pulls dependencies automagically and lets you change version by merely changing the release number.

• Making the build process easy
• Providing a uniform build system
• Providing quality project information
• Providing guidelines for best practices development
• Allowing transparent migration to new features
• Change log document created directly from source control
• Cross referenced sources
• Mailing lists
• Dependency list
• Unit test reports including coverage
• Keeping your test source code in a separate, but parallel source tree
• Using test case naming conventions to locate and execute tests
• Have test cases setup their environment and don’t rely on customizing the build for test preparation.

---

ENABLING LOGGING LEVELS AND TRACES IN THE OSGI CONSOLE

Lets say you want to see all log messages from the bundle. Change the logging level to arphandler to trace from the OSGI console.

Next verify your logging level.

Logs will appear in the OSGI console and also in your opendaylight.log file.

To enable logging in a bundle the following is an example. I am assuming each bundle will maintain separate logging per class/bundle for logical separation.

BUILDING OPENDAYLIGHT MODULES INDIVIDUALLY AFTER CHANGING THE CODE

Once you edit code on an individual bundle, you need to rebuild the bundle for the code to take effect. It is way to slow to rebuild the entire platform, not to mention very un-agileish.

First, if the project is running, stop the module with the following from the OSGI console. In this case I am using the arphandler bundle as an example.

Next, rebuild the bundle. When you build the project using mvn clean install, it will delete the existing jar file and create a new one. In order to get the new jar to load it needs to match the pom.xml loaded module. That is why I copy it in the second line in the following snippet.

Finally load the new jar into the framework. The cool thing is the JVM was never stopped in this process.

You can also never stop the bundle and perform an upgrade using OSGI with:

OSGI will pull the current jar in the path and reload it.

HACKING BUNDLES : CREATE YOUR OWN MODULE

I am using bundles and projects (right or wrong) interchangeably. There are various ways to start bundles, but an easy starter could be to copy and paste an existing application. There are some example application bundles located in the “~/controller/opendaylight/samples/” directory. It can also be done using declarative services, but I have not explored that yet. This is just a total sample of how to hack and even better break things to learn the OSGI/Maven framework and the code order of operations. Keep in mind, there isn’t a main method with OSGI. It is more of blob projects/modules/bundles can plug into and dynamically loaded and unloaded without restarting the entire JVM.

Copy and application like samples.simpleforwarding and paste it into the project explorer.
Edit the project bundle pom.xml to match your new bundle: ~/controller/opendaylight/samples/simpleforwarding
Edit the parent pom.xml located in distribution.opendaylight and add the new bundle: ~/controller/opendaylight/distribution/opendaylight/pom.xml. The parent pom.xml denoted by is located in opendaylight/commons/opendaylight/pom.xml
The Activator.java can be used to start/stop/initialize/destroy bundles into the JVM. Simple examples are two methods starting a bundle, start/stop.

Project Object Model or POM is the main piece of Maven that ties all of the projects in together. Each project has a pom.xml and the whole platform has a super pom.xml. The format is XML and fairly easy to discern what is going on. There is a patch in from David Erickson to bring the net-virt platform into the controller which will be awesome. The net-virt L2 forwarding module is very mature coupled with its host tracker. I hope to use it in production soon to proof reactive BUM traffic scale (may need a job:-).

UPDATE OPENDAYLIGHT USING GIT

Running git pull from anywhere south of the parent controller directory will update the code set. Then just rebuild it w/ mvn clean install. mvn clean will delete the existing built jars. Install will build and leave them in the target directory.

You can always manually install jars with the following:

MORE OPENDAYLIGHT HOW-TOS

We are starting to have a good list of resources. Hack around and break it and fix it. I am great at the breaking part personally. Dont be overwhelmed, if you want to learn ODP or even programming you can if you put in the time. It is a unique time in networking to shape the future.

See more blogs from the ODP community and visit the OpenDaylight Wiki. If you do any how-tos feel free to shoot them to me and I will post them on the wiki.

---

• Join the OpenDaylight IRC channel at irc.freenode.net at #opendaylight and colaborate with others from the community.
• Listen to the TSC calls weekly Weekly TSC and Technical Work Stream Calls.

---

Join the ODP Listserv →

Come Help Us Code in the OVSDB Project →

Check Out Our Recordings of the OVSDB Project →

---

Regardless of any claims, no one really knows what the future of networking should or will be but open source is a safe bet based on history. Companies like Red Hat and IBM are well positioned in the Daylight project so keep that in mind when parsing through the FUD. Little if any of SDN is proofed beyond a few fixed scenarios. It is a great chance for both vendors and community to collaborate and evolve together for the future. The Linux Foundation is an appropriate organization for ODP to be under the auspices of. OpenDaylight has the makings of becoming the Linux kernel of networking.

To get there it will take community. The TSC’s role should be focused on community enablement. The broader OpenDaylight project goal should not only be bootstrapping code, but the equally important mission of bootstrapping a the fledgling network community. The vendors on the IRC channel everyday helping field dev questions are nothing short of phenomenal. Come grow with networking, I am happy to help, as are others in channel. No such thing as dumb questions.