A strawman controller integration strategy


Rob Sherwood
 

[note: this is all likely premature and the technical feasibility of it needs to be investigated, but this is a path forward that *if* it works, I think might make sense]

The big question that we're facing right now is: what do we do with two code bases that have some still-actively-being-understood amount of overlap?

A few of us have been chatting (I'll let each of you out yourself :-) and have come up with a tentative plan of how this might be done.  Let me be clear that we're still outlining this plan and it's not clear if this will work, how it will work, even before we get to the big question of: is there actually consensus to do this.

Short story, from the net-virt-platform[1] world view, there is a base platform that provides all sorts of goodies[2] in terms of end-host discovery, switch discovery, forwarding control, multi-tenancy, etc.  And people build applications on top of it, like the VNS application (soon to be pulled out into a separate repo), that leverage these features.

If I can approximate my understanding of the controller.git code, their SAL builds upon their openflow driver to achieve many of the same properties.  In theory, their SAL supports multiple southbound protocols via pluggable drivers and is extensible to support lots of additional APIs.

My high-level hand wavy contention is that we can:
1) separate out *just the platform* part of the net-virt-platform
2) write a SAL plugin for it that exposes the net-virt-platform APIs through the SAL
3) take the VNS application and run it on top on the SAL

So, from the net-virt's perspective, the SAL is an application like any other.  From the SAL's perspective, net-virt is a southbound plugin, like any other.

Somewhat surprisingly, the code bases are seemingly quite compatible and this does not seem entirely impossible.  I'm looking for people to help me investigate how we could go about assessing this and maybe even doing some prototyping.  We're certainly trying to staff things up on our side but I think if we could make some early progress on this it might be useful from a timing perspective.

So, the work would look like:

1) create OSGI containers for all of the modules in net-virt (I've got someone working on this already)
2) refactor the current ant-build system to use maven
3) to start better understand the southbound SAL plugin interface

Re: the "SAL plugin interface" part - can someone familiar with the code point me in the right direction?  There doesn't seem to be a ISouthboundSAL.java or similar and looking at the openflow plugin doesn't seem to provide clarity either.  Any help would be appreciated.

But, short story, what do people think about this tack?

- Rob
.

[1] I'm going to be a bit picky about calling the project net-virt-platform, because it's about 4x more code than floodlight and very close to our actual commercial Big Network Controller and Big Virtual Switch products.


Colin Dixon <ckd@...>
 

Without commenting on the rest of the mail—which will take much longer—the place to start looking at the SAL is the org.opendaylight.controller.sal.implementation.internal bundle. The exported interfaces are listed on the wiki page which you reference here:
https://wiki.opendaylight.org/view/Controller_Project%27s_Modules/Bundles_and_Interfaces

I think the short list is that it must provide the following interfaces to be compatible with the current SAL;
IReadService
IPluginOutTopologyService
ITopologyService
IInventoryService
IPluginOutInventoryService
IFlowProgrammerService
IPluginOutFlowProgrammerService
IPluginOutDataPacketService
IDataPacketService

Thanks,
--Colin

discuss-bounces@... wrote on 04/30/2013 02:38:08 PM:
> From: Rob Sherwood <rob.sherwood@...>

> To: discuss@...
> Date: 04/30/2013 02:39 PM
> Subject: [OpenDaylight Discuss] A strawman controller integration strategy
> Sent by: discuss-bounces@...
>
> Re: the "SAL plugin interface" part - can someone familiar with the
> code point me in the right direction?  There doesn't seem to be a
> ISouthboundSAL.java or similar and looking at the openflow plugin
> doesn't seem to provide clarity either.  Any help would be appreciated.

>
> But, short story, what do people think about this tack?