OpenDaylight Architecture++

Michael Vorburger.ch

Architecture Evolution Wish List

1. Lighter weight

2. etcd data store (POC - resources??)

3. Distributed (*)

​

Light weight?

ODL is currently built on Apache Karaf “Middleware” - an OSGi run-time container. This is very niche and exotic in the bigger picture of things in Java land. Drawbacks include:

Development Overhead Runtime Overhead Future Proof

• Learning Curve - Start-up time (K8s..) - Custom Distro
• Local Dev turn around - Memory (*) - Distributed
• 3rd party libs int. - Security - Microservices
• Tests - Agents?
• Debug - “Edge”?

Huh?

Run EXACT same code!!!

Just the run-time is different (none) [add. dist. not instead]

No more run-time feature installation (-)

Optional (?) CLI & built-in SSH server

Microservices

Reference / Image credit : https://martinfowler.com/articles/microservices.html

How to write Distributed Micro Service Apps?

Perhaps not by extending an SDN (sic!) controller’s technical platform?

For Remoting, Messaging, Monitoring and Tracing, etc. etc. probably best to align with and rely on existing (or emerging..) industry best practices. Guess what, Red Hat has some stuff in this space - and some cool new things up its sleeves, still TBC in public.

Simplification work can be a foundation for further exploring this - later.

Status?

Currently driven mostly just by myself.

Basic POC concluded, now WIP to close known gaps.

Some contributions from Ericsson & Lumina in 2018.12.

​

https://github.com/vorburger/opendaylight-simple

https://git.opendaylight.org/gerrit/#/q/topic:simple-dist

OpenDaylight-SIMPLE

Sep 22/23, 2018 @ Neon Developer Design Forum (Amsterdam)

Michael Vorburger.ch, Red Hat

A (personal) perspective

based on 2.5 years hacking on ODL, and an exploration of an alternative in https://github.com/vorburger/opendaylight-simple

Keeping this quick & high-level, leaving time for someone else with similar ideas (coincidence, AFAIK; separate initiatives) speaking after. My goal is to share & gauge interest.

Why OSGi is so great!

• Modularity - not just at build time but even at runtime! Isolation, Deps.
• Solves “classpath hell” (except API...) - several JAR versions coexist!
• Except with “version convergence” by odlparent in ODL, that’s not an issue.
• HOT runtime “feature” (de)installation and in-place replace - whoa!
• Cool. Except... NOBODY actually does this. Restarting (clustered) is just fine.
• Even more on https://www.osgi.org/developer/benefits-of-using-osgi/ (BS*) ...�

PS, FYI: I even run Minecraft and Maven & Gradle builds in OSGi!!! ❤️

Why OSGi is therefore so widely used… cough

• Eclipse
• Fuse ESB (Red Hat), Apache Camel
• openHAB home automation (*)
• Embedded space, set -top, cars, ...
• and us, OpenDaylight
• ...

And then “some” Spring [Boot] and JBoss / WildFly / Swarm / Thorntail etc. apps out there, in the wild...

~ Some Numbers ~ (! APPROXIMATIVE !)

https://github.com/search?q=java : Code 337M+�https://github.com/search?q=[org.]osgi : Code 2M ~ 0.6% / all Java�https://github.com/search?q=springframework : Code 34M ~ 10% / all Java�

https://www.google.ch/search?q=org.springframework : 7.1M�https://www.google.ch/search?q=org.osgi : 1.9M (wow, hm)�https://www.google.ch/search?q=java : 526M

Obviously ODL does not actually need the Spring Framework - that’s not the message here.

Why OSGi can be not so great..

Increases cost for any 3rd party library integration (like a tax).

Local development turnaround productivity is relatively poor (MVN).

Ask anyone who ever debugged a SingleFeatureTest (SFT) failure? ;)

It’s basically just really “niche”, in the overall Java ecosystem. Check SO.

This costs us real productivity time and money overhead, IMHO.

Karaf, OSGi & Modularity

• feature.xml and feature:install = Karaf != OSGi�Not actually used IRL? Anyway containerized. ODL.org DL gimmick?
• There are alternative models… E.g. Launcher of Apache Sling, the FLOSS foundation of Adobe’s CMS (orig by Day.CH), just starts set of OSGi bundles fixed at boot time - no dynamic feature installation.
• IMHO not even that is needed (but could be the fallback plan…)�

So perhaps we could just fix sets of modules assembled at build time?

How? And how VS today’s code??

What we would actually need? NOT really the Spring framework, but:

• Wiring via @Singleton and @Inject (blueprint-maven-plugin)
• Console commands?!? Karaf specific API.
• Clean up code relying on OSGi APIs.
• Logging (easy)

We can more seriously gradually explore this in parallel...

github.com/vorburger/opendaylight-simple

• ^{Tried it, and (almost ;) got it working, up to genius!}
• ^{Q: Blueprint Wiring? A: Guice. Or CDI, Spring, …}
• ^{Q: Karaf CLI ? A: Not a big problem - solved.}
• ^{So done? ;) Not quite.. more un-OSGi code clean up.}

^#helpwanted

Deployment/Use Case Specific Distributions?

opendaylight-simple currently has fixed feature list, at build time in POM.

​

But if we agreed that we wanted to keep a “FAT distribution” including all ODL projects’ many JARs in a single ZIP like today’s DL-able release on Karaf, that’s technically still totally feasible even with this model IMHO.

​

It could have a “feature list” which determines which DI Modules start.

​

It just would be at boot time instead of at runtime. Would that work?

Q & A