Having worked as an OpenDaylight developer for some time, I participated in many customer projects based on OpenDayght’s Boron, Carbon, Nitrogen, and Oxygen releases. OpenDaylight, as a software-defined networking platform has an interesting concept of “model-driven architecture”, where features of the SDN controller are using MD-SAL to interact with each other.
It is on top of this layer, that the OpenDaylight project family builds other very interesting projects, that are practical for SDN application development. To name few: NETCONF and RESTCONF plugins, YANG Tools and Java YANG binding generation, BGP and PCEP plugins (for core networks), TransportPCE (optical switch management), OpenFlow, Neutron (ODL as OpenStack network controller), GBP for intent-based networking, and many others.
Real life challenges
Real project life usually brings additional challenges for everyday SDN application developer. The fast-changing market environment requires rapid application development with retained features such as high reliability, scalability, and security.
Micro-service SDN deployments require very fast startup and shutdown times and small memory footprint. Project operating cost has to be kept low, meaning that continuous integration and the testing process must be easy and very fast.
The learning curve for new team members cannot be steep. Latest Java 9 release with its highly anticipated platform module system also adds pressure to upgrade JVM and application libraries.
The Karaf Issue
Using OpenDaylight community release for everyday SDN application development does not exactly fit the bill. Even if OpenDaylight itself is an interesting product, Apache Karaf framework and complexity of OpenDaylight’s Karaf features is quite problematic, introducing higher costs for testing, integration, and maintenance.
The latest OpenDaylight Nitrogen release is not addressing complexity issues quite well. Therefore, my team and I have been working hard to substantially improve SDN development experience, lower the development costs and help application teams to focus on SDN core business.
Our Experience
Our experiences with other Java frameworks like spring.io, vertx.io, and projects like jetty, jersey, grpc.io or akka.io were telling us that there has to be a better way to develop on this platform. That is how lighty.io was born. The “from developers, for developers” part of lighty.io, provides a set of Java SE components without the use of Karaf framework, with the following advantages:
• Client libraries for communication with ODL backend for Java, Python, and Golang
• Enhanced NETCONF device simulator
• Easy-to-use utilities for YANG model data serialization and deserialization
• Example applications for integration with vertx.io, spring.io & more
By creating a lighter environment, without building specifically on any framework, lighty.io offers OpenDaylight components adapted for plain Java runtime. This is what it takes to start MD-SAL controller with RESTCONF northbound plugin:
public class Main {
public static void main(String[] args) throws Exception {
//1. initialize lighty.io core services, which involves
// OpenDaylight controller (MD-SAL, Controller, YangTools, Akka)
ControllerConfiguration controllerConfiguration =
ControllerConfigUtils.getDefaultSingleNodeConfiguration(models);
LightyController lightyController = new LightyControllerBuilder()
.from(controllerConfiguration)
.build();
lightyController.start().get();
//2. start RestConf server
RestConfConfiguration restConfConfiguration = RestConfConfigUtils.getDefaultRestConfConfiguration();
CommunityRestConf communityRestConf = new CommunityRestConfBuilder()
.from(RestConfConfigUtils.getRestConfConfiguration(
restConfConfiguration, lightyController.getServices()))
.build();
communityRestConf.start().get();
//3. start NetConf South-bound plugin
NetconfConfiguration netconfSBPConfig = NetconfConfigUtils.createDefaultNetconfConfiguration();
netconfSBPConfig = NetconfConfigUtils.injectServicesToTopologyConfig(
netconfSBPConfig, lightyController.getServices());
LightyModule netconfSouthboundPlugin = new NetconfTopologyPluginBuilder()
.from(netconfSBPConfig, lightyController.getServices())
.build();
netconfSouthboundPlugin.start().get();
}
}
Starting SDN controller application is just a few lines of Java code. Writing complex integration tests in Java is also easy because all tested components are running in a single JVM. This means they can be easily orchestrated and tested.
Simple application test below starts full controller application and performs an HTTP GET request via RESTCONF on topology data.
public class ApplicationTest {
private HttpClient httpClient;
@BeforeTest
public void init() throws Exception {
Main.start();
httpClient = new HttpClient();
httpClient.start();
}
/**
* Simple integration test which starts application and checks if RESTCONF north-bound interface is responding.
* As this test starts full instance of ODL controller and RESTCONF http server on port 8888, this port must
* be free prior to the test. This test and tested application runs in single JVM instance.
* !!! Make sure port 8888 is open on localhost !!!
*/
@Test
public void sanityTest() throws Exception {
ContentResponse get = httpClient.GET("http://localhost:8888/restconf/data/network-topology:network-topology");
Assert.assertEquals(get.getStatus(), 200);
LOG.info("sanityTest done.");
}
@AfterTest
public void destroy() throws Exception {
Main.shutdown();
httpClient.stop();
}
}
Beyond that, we developed several components that are really missing in the OpenDaylight ecosystem to speed-up our testing and development:
• Client libraries for communication with ODL backend for Java, Python & Golang
• Enhanced NETCONF device simulator
• Easy-to-use utilities for YANG model data serialization and deserialization
• Example applications for integration with vertx.io, spring
By developing lighty.io, our team contributes to upstream OpenDaylight projects as well as creates new components like the RESTCONF module, fully compliant with RFC8040. The nice thing about lighty.io is, that your application code becomes more versatile.
If written properly, the same code can be deployed in an OpenDaylight Karaf runtime, started as a Java SE lighty.io application or deployed into the framework of lighty.io and how can you leverage lighty.io, even if you are not a developer.
Juraj Veverka
