ENOS / ODL separation

[bmah888]

@bmah888 commented on Mon Apr 25 2016

Currently, ENOS with ODL integration requires that Netshell and ENOS run inside the Karaf container being used by ODL. There are several reasons to remove this requirement:

• Decouple ENOS and ODL, to permit adoption of a different OpenFlow controller in the future, either as a replacement or supplement to ODL.
• Make it possible for a single ENOS instance to use multiple ODL (or other) OpenFlow instances.
• Allow us to turn the ENOS security manager back on if so desired.
• Allow us more freedom in development (use newer Java, use newer Karaf, no Karaf at all, etc.).
• Faster deployment, startup, and development by not needing to repeatedly restart ODL.
• Deploy software components that conflict with ODL container environment (RESTful services, etc.).

Some work in this area has already been done by implementing an internal RMQ interface between an OpenFlow driver and a provider of OpenFlow services. The RMQ interface is message-based, and implements something similar to an RPC facililty for programming and manipulating flows, plus an asynchronous notification for PACKET_IN events.

To complete the separation, the following work items are required:

• Split netshell-controller into three pieces, each of which should be made into its own OSGi bundle. The first is the "client" side that is invoked by ENOS code (net.es.netshell.controller.client). It should probably be renamed "OpenFlowDriver" or something similar. The second piece consists of the bits that need to run in ODL Karaf (net.es.netshell.controller.core and net.es.netshell.controller.impl). These two packages could probably be combined into one, called OpenDaylightProvider. The final piece consists of the definitions of the RMQ messages and common constants that are needed by the first two pieces.
• Part of the step above also requires auditing the existing code to be sure that the parts that go with ODL have no ENOS dependencies and vice versa.
• Allow the OpenFlowDriver and OpenDaylightProvider parts to specify which RMQ queues to use for communication.
• Adjust Maven project dependencies and OSGi bundle dependencies. This will be the first time that something built as a part of Netshell will not be deployed along with the rest of Netshell.

Filing this issue to document a rough plan for doing the work, if and when we decide to do it. It should not be conceptually difficult because the RMQ interface has already been created and is being used today. The problems will mostly be in making sure the implementation can be deployable, we don't have any unwanted dependencies, etc.

[bmah888]

Note that the following commits (on a branch for now) are work-in-progress commits for this issue:

e47acfecdfc3ea74ed3489ced98fd775a785a05a

c93ebf4f48410be86f2098779babb70c633168cf

The linkages to this issue were not noted in their commit messages.

[bmah888]

Briefly tested. I'm going to call this work "done" for now.