Jump to: navigation, search

Dixon-Erickson OpenDaylight Merged Controller Proposal

NOTE: We would like to explicitly ask for feedback from *all* consortium members on this proposal rather than only the members who have currently contributed code bases.

We have examined both the controller and net-virt-platform codebases in detail, and considered the requirements from the architectural principals page and the requested deliverable timeline when creating these recommendations. Our recommendation's structure is composed of a set of features we believe should be in the final deliverable, which component(s) implement each feature in the existing projects, along with a recommendation on what component(s) should be inside each final feature. As expected, there is significant code that can be leveraged from both projects and used to create the best deliverable possible.

At a core level we believe OSGi to be the right technology to enable runtime modularity and extensibility. Further, we believe that the layer of indirection introduced by a SAL is critical; though, we have several suggestions for improving the SAL as well. Thus, we suggest that the OSGi-related architecture components in the OpenDaylight controller project, and in particular the SAL, be used as a starting point for the core*. Code being brought from the net-virt-platform should be easily convertible to use this architecture. We differ in our thoughts on where to house the new code. David recommends that a new project and repository be created to contain this new combined code while Colin feels that the appropriate place to address these concerns is the life cycle requirements for projects to have (merit-selected) committers from multiple companies for them be promoted to certain life cycle stages.

(*) We also believe there are flaws with the way OSGi is currently being used, i.e., the use of strings for binding in Activator code and the inability to integrate with the Eclipse incremental build-on-save (PDE) system, and strongly encourage them to be addressed sooner rather than later.

This is not intended to provide a function-level or line-level description of what needs to happen, but to at a high-level assess the features that we feel a controller should have and identify the most promising sources of those features as well as any further discussion that needs to happen around certain areas. We note that there is likely a valid discussion to be had around what parts of this should actually go into a core controller project/repository and if any of it should be factored out into their own projects, but we consider that outside of the scope of this document. In practice, the code need not be completely contained in one project, but merely needs to produce compatible OSGi bundles and publish them to a common bundle repository.

In the attached spreadsheet, we refer to the OpenDaylight controller project as "controller" (with the quotes) to disambiguate it from the general term controller. We refer to the OpenDaylight net-virt-platform project as net-virt-platform. Note that the OpenDaylight controller project is referred to as "OpenDaylight Controller" on the wiki and that the OpenDaylight net-virt-platform project is referred to as "OpenDaylight SDN Controller Platform" on the wiki.