the modules/bundles and exported interfaces of the two code bases


Colin Dixon <ckd@...>
 

Hi Everyone,

Here's a first cut at a list of the modules/bundles in each controller and the interfaces they export. I used the version of Floodlight that is available on github rather than the current net-virt-platform code base because that's what I had loaded up in Eclipse when I started this process. Obviously, there are going to be some changes, but I think they are minor.

Throughout the mail I'll use Floodlight to refer to the Floodlight code base and Daylight to refer to the controller project currently hosted on the OpenDaylight git repositories. Hopefully, this will simplify the discussion.

After playing around for a while I generated this list by searching for implementations of net.floodlightcontroller.core.module.IFloodlightModule.getModuleServices() in Floodlight and all calls to org.osgi.framework.ServiceRegistration.Component.setInterface() in the Daylight code. Note that there are two implementations of the second function: one that takes a single interface and one that takes a list.

I classified the Floodlight code into a hierarchy of package => module => interface since that was pretty easy. I classified the Daylight code into a hierarchy of package/bundle => interface. In practice, I think that there's a 1:1 correspondence between packages and bundles in the Daylight code, so that's fine. However, there is no real notion of a "module" in Daylight which is easy to pull out. The result is that I can really only get per-bundle information.

In reality, it seems like there's something of a concept of a module in the Daylight code, but it's weakly codified. Basically, in implementations of org.opendaylight.controller.sal.core.ComponentActivatorAbstractBase.configureInstance() and org.opendaylight.controller.sal.core.ComponentActivatorAbstractBase.configureGlobalInstance(), they pass the particular implementation being activated and based on that they change the interfaces. In some cases, the package/bundle only has one such expected implementation and thus they don't ever use it. In other cases it has multiple, which are effectively modules, and it modifies it's behavior depending on which implementation is passed back.

Hopefully, this will provide at least a sound technical backing for discussions going forward.

--Colin


Floodlight: (packages => modules => interfaces exported)
net.floodlightcontroller.core
OFMessageFilterManager
IOFMessageFilterManagerService
FloodlightProvider/Controller
IFloodlightProviderService
net.floodlightcontroller.counter
CounterStore
ICounterStoreService
NullCounterStore
ICounterStoreService
net.floodlightcontroller.devicemanager.internal
DefaultEntityClassifier
IEntityClassifierService
DeviceManagerImpl
IDeviceService
net.floodlightcontroller.firewall
Firewall
IFirewallService
net.floodlightcontroller.flowcache
FlowCache
IFlowCacheService
FlowReconcileManager
IFlowReconcileService
PortDownReconciliation
(none)
net.floodlightcontroller.forwarding
Forwarding
(none)
net.floodlightcontroller.hub
Hub
(none)
net.floodlightcontroller.jython
JythonDebugInterface
(none)
net.floodlightcontroller.learningswitch
LearningSwitch
ILearningSwitchService
net.floodlightcontroller.linkdiscovery.internal
LinkDiscoveryManager
ILinkDiscoveryService
net.floodlightcontroller.loadbalancer
LoadBalancer
ILoadBalancerService
net.floodlightcontroller.perfmon
NullPktInProcessingTime
IPktInProcessingTimeService
PktInProcessingTime
IPktInProcessingTimeService
net.floodlightcontroller.restserver
RestApiServer
IRestApiService
net.floodlightcontroller.staticflowentry
StaticFlowEntryPusher
IStaticFlowEntryPusherService
net.floodlightcontroller.storage
AbstractStorageSource
IStorageSourceService
NoSqlStorageSource
IStorageSourceService
net.floodlightcontroller.threadpool
ThreadPool
IThreadPoolService
net.floodlightcontroller.topology
TopologyManager
ITopologyService
IRoutingService
net.floodlightcontroller.ui.web
StaticWebRoutable
(none)
net.floodlightcontroller.virtualnetwork
VirtualNetworkFilter
IVirtualNetworkService

Daylight: (packages/bundles => interfaces exported)
org.opendaylight.controller.arphandler.internal
IHostFinder
IListenDataPacket
org.opendaylight.controller.clustering.services_implementation.internal
IClusterContainerServices
IClusterServices
IClusterGlobalServices
org.opendaylight.controller.clustering.stub.internal
IClusterContainerServices
IClusterGlobalServices
org.opendaylight.controller.configuration.internal
IConfigurationService
IConfigurationContainerService
IConfigurationAware
org.opendaylight.controller.containermanager.internal
IContainerManager
IContainer
org.opendaylight.controller.forwarding.staticrouting.internal
IForwardingStaticRouting
ICacheUpdateAware
IfNewHostNotify
IConfigurationContainerAware
org.opendaylight.controller.forwardingrulesmanager.internal
IContainerListener
ISwitchManagerAware
IForwardingRulesManager
IInventoryListener
ICacheUpdateAware
IConfigurationContainerAware
IFlowProgrammerListener
org.opendaylight.controller.hosttracker.internal
ISwitchManagerAware
IInventoryListener
IfIptoHost
IfHostListener
ITopologyManagerAware
org.opendaylight.controller.protocol_plugin.openflow.internal
IContainerListener
IController
IDataPacketListen
IDataPacketMux
IDiscoveryService
IFlowProgrammerNotifier
IInventoryShimExternalListener
IMessageListener
IOFStatisticsManager
IPluginInDataPacketService
IPluginInFlowProgrammerService
IPluginInInventoryService
IPluginInReadService
IPluginInTopologyService
IPluginReadServiceFilter
IRefreshInternalProvider
IStatisticsListener
ITopologyServiceShimListener
org.opendaylight.controller.protocol_plugins.stub.internal
IPluginInReadService
org.opendaylight.controller.routing.dijkstra_implementation.internal
ITopologyManagerAware
IRouting
org.opendaylight.controller.sal.implementation.internal
IReadService
IPluginOutTopologyService
ITopologyService
IInventoryService
IPluginOutInventoryService
IFlowProgrammerService
IPluginOutFlowProgrammerService
IPluginOutDataPacketService
IDataPacketService
org.opendaylight.controller.samples.loadbalancer.internal
IListenDataPacket
IConfigManager
org.opendaylight.controller.samples.simpleforwarding.internal
IInventoryListener
IfNewHostNotify
IListenRoutingUpdates
org.opendaylight.controller.statisticsmanager.internal
IStatisticsManager
org.opendaylight.controller.switchmanager.internal
IListenInventoryUpdates
ISwitchManager
ICacheUpdateAware
IConfigurationContainerAware
org.opendaylight.controller.topologymanager.internal
IListenTopoUpdates
ITopologyManager
IConfigurationContainerAware
org.opendaylight.controller.usermanager.internal
ICacheUpdateAware
IUserManager
IConfigurationAware


David Meyer <dmm@...>
 

Thanks Colin! --dmm


On Mon, Apr 29, 2013 at 12:23 PM, Colin Dixon <ckd@...> wrote:

Hi Everyone,

Here's a first cut at a list of the modules/bundles in each controller and the interfaces they export. I used the version of Floodlight that is available on github rather than the current net-virt-platform code base because that's what I had loaded up in Eclipse when I started this process. Obviously, there are going to be some changes, but I think they are minor.

Throughout the mail I'll use Floodlight to refer to the Floodlight code base and Daylight to refer to the controller project currently hosted on the OpenDaylight git repositories. Hopefully, this will simplify the discussion.

After playing around for a while I generated this list by searching for implementations of net.floodlightcontroller.core.module.IFloodlightModule.getModuleServices() in Floodlight and all calls to org.osgi.framework.ServiceRegistration.Component.setInterface() in the Daylight code. Note that there are two implementations of the second function: one that takes a single interface and one that takes a list.

I classified the Floodlight code into a hierarchy of package => module => interface since that was pretty easy. I classified the Daylight code into a hierarchy of package/bundle => interface. In practice, I think that there's a 1:1 correspondence between packages and bundles in the Daylight code, so that's fine. However, there is no real notion of a "module" in Daylight which is easy to pull out. The result is that I can really only get per-bundle information.

In reality, it seems like there's something of a concept of a module in the Daylight code, but it's weakly codified. Basically, in implementations of org.opendaylight.controller.sal.core.ComponentActivatorAbstractBase.configureInstance() and org.opendaylight.controller.sal.core.ComponentActivatorAbstractBase.configureGlobalInstance(), they pass the particular implementation being activated and based on that they change the interfaces. In some cases, the package/bundle only has one such expected implementation and thus they don't ever use it. In other cases it has multiple, which are effectively modules, and it modifies it's behavior depending on which implementation is passed back.

Hopefully, this will provide at least a sound technical backing for discussions going forward.

--Colin


Floodlight: (packages => modules => interfaces exported)
net.floodlightcontroller.core
OFMessageFilterManager
IOFMessageFilterManagerService
FloodlightProvider/Controller
IFloodlightProviderService
net.floodlightcontroller.counter
CounterStore
ICounterStoreService
NullCounterStore
ICounterStoreService
net.floodlightcontroller.devicemanager.internal
DefaultEntityClassifier
IEntityClassifierService
DeviceManagerImpl
IDeviceService
net.floodlightcontroller.firewall
Firewall
IFirewallService
net.floodlightcontroller.flowcache
FlowCache
IFlowCacheService
FlowReconcileManager
IFlowReconcileService
PortDownReconciliation
(none)
net.floodlightcontroller.forwarding
Forwarding
(none)
net.floodlightcontroller.hub
Hub
(none)
net.floodlightcontroller.jython
JythonDebugInterface
(none)
net.floodlightcontroller.learningswitch
LearningSwitch
ILearningSwitchService
net.floodlightcontroller.linkdiscovery.internal
LinkDiscoveryManager
ILinkDiscoveryService
net.floodlightcontroller.loadbalancer
LoadBalancer
ILoadBalancerService
net.floodlightcontroller.perfmon
NullPktInProcessingTime
IPktInProcessingTimeService
PktInProcessingTime
IPktInProcessingTimeService
net.floodlightcontroller.restserver
RestApiServer
IRestApiService
net.floodlightcontroller.staticflowentry
StaticFlowEntryPusher
IStaticFlowEntryPusherService
net.floodlightcontroller.storage
AbstractStorageSource
IStorageSourceService
NoSqlStorageSource
IStorageSourceService
net.floodlightcontroller.threadpool
ThreadPool
IThreadPoolService
net.floodlightcontroller.topology
TopologyManager
ITopologyService
IRoutingService
net.floodlightcontroller.ui.web
StaticWebRoutable
(none)
net.floodlightcontroller.virtualnetwork
VirtualNetworkFilter
IVirtualNetworkService

Daylight: (packages/bundles => interfaces exported)
org.opendaylight.controller.arphandler.internal
IHostFinder
IListenDataPacket
org.opendaylight.controller.clustering.services_implementation.internal
IClusterContainerServices
IClusterServices
IClusterGlobalServices
org.opendaylight.controller.clustering.stub.internal
IClusterContainerServices
IClusterGlobalServices
org.opendaylight.controller.configuration.internal
IConfigurationService
IConfigurationContainerService
IConfigurationAware
org.opendaylight.controller.containermanager.internal
IContainerManager
IContainer
org.opendaylight.controller.forwarding.staticrouting.internal
IForwardingStaticRouting
ICacheUpdateAware
IfNewHostNotify
IConfigurationContainerAware
org.opendaylight.controller.forwardingrulesmanager.internal
IContainerListener
ISwitchManagerAware
IForwardingRulesManager
IInventoryListener
ICacheUpdateAware
IConfigurationContainerAware
IFlowProgrammerListener
org.opendaylight.controller.hosttracker.internal
ISwitchManagerAware
IInventoryListener
IfIptoHost
IfHostListener
ITopologyManagerAware
org.opendaylight.controller.protocol_plugin.openflow.internal
IContainerListener
IController
IDataPacketListen
IDataPacketMux
IDiscoveryService
IFlowProgrammerNotifier
IInventoryShimExternalListener
IMessageListener
IOFStatisticsManager
IPluginInDataPacketService
IPluginInFlowProgrammerService
IPluginInInventoryService
IPluginInReadService
IPluginInTopologyService
IPluginReadServiceFilter
IRefreshInternalProvider
IStatisticsListener
ITopologyServiceShimListener
org.opendaylight.controller.protocol_plugins.stub.internal
IPluginInReadService
org.opendaylight.controller.routing.dijkstra_implementation.internal
ITopologyManagerAware
IRouting
org.opendaylight.controller.sal.implementation.internal
IReadService
IPluginOutTopologyService
ITopologyService
IInventoryService
IPluginOutInventoryService
IFlowProgrammerService
IPluginOutFlowProgrammerService
IPluginOutDataPacketService
IDataPacketService
org.opendaylight.controller.samples.loadbalancer.internal
IListenDataPacket
IConfigManager
org.opendaylight.controller.samples.simpleforwarding.internal
IInventoryListener
IfNewHostNotify
IListenRoutingUpdates
org.opendaylight.controller.statisticsmanager.internal
IStatisticsManager
org.opendaylight.controller.switchmanager.internal
IListenInventoryUpdates
ISwitchManager
ICacheUpdateAware
IConfigurationContainerAware
org.opendaylight.controller.topologymanager.internal
IListenTopoUpdates
ITopologyManager
IConfigurationContainerAware
org.opendaylight.controller.usermanager.internal
ICacheUpdateAware
IUserManager
IConfigurationAware


_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss



Colin Dixon <ckd@...>
 

The list seems to have lost the formatting of my document, so I'm attaching it to this mail and I posted it to the wiki here:
https://wiki.opendaylight.org/view/Controller_Project%27s_Modules/Bundles_and_Interfaces

--Colin

(See attached file: modules-bundles-interfaces.txt)

discuss-bounces@... wrote on 04/29/2013 02:23:09 PM:
> From: Colin Dixon/Austin/IBM@IBMUS

> To: discuss@...
> Date: 04/29/2013 02:25 PM
> Subject: [OpenDaylight Discuss] the modules/bundles and exported
> interfaces of the two code bases

> Sent by: discuss-bounces@...
>
> Hi Everyone,
>
> Here's a first cut at a list of the modules/bundles in each
> controller and the interfaces they export. I used the version of
> Floodlight that is available on github rather than the current net-
> virt-platform code base because that's what I had loaded up in
> Eclipse when I started this process. Obviously, there are going to
> be some changes, but I think they are minor.
>
> Throughout the mail I'll use Floodlight to refer to the Floodlight
> code base and Daylight to refer to the controller project currently
> hosted on the OpenDaylight git repositories. Hopefully, this will
> simplify the discussion.
>
> After playing around for a while I generated this list by searching
> for implementations of
> net.floodlightcontroller.core.module.IFloodlightModule.getModuleServices
> () in Floodlight and all calls to
> org.osgi.framework.ServiceRegistration.Component.setInterface() in
> the Daylight code. Note that there are two implementations of the
> second function: one that takes a single interface and one that takes a list.
>
> I classified the Floodlight code into a hierarchy of package =>
> module => interface since that was pretty easy. I classified the
> Daylight code into a hierarchy of package/bundle => interface. In
> practice, I think that there's a 1:1 correspondence between packages
> and bundles in the Daylight code, so that's fine. However, there is
> no real notion of a "module" in Daylight which is easy to pull out.
> The result is that I can really only get per-bundle information.
>
> In reality, it seems like there's something of a concept of a module
> in the Daylight code, but it's weakly codified. Basically, in
> implementations of
> org.opendaylight.controller.sal.core.ComponentActivatorAbstractBase.configureInstance
> () and
> org.opendaylight.controller.sal.core.ComponentActivatorAbstractBase.configureGlobalInstance
> (), they pass the particular implementation being activated and
> based on that they change the interfaces. In some cases, the
> package/bundle only has one such expected implementation and thus
> they don't ever use it. In other cases it has multiple, which are
> effectively modules, and it modifies it's behavior depending on
> which implementation is passed back.
>
> Hopefully, this will provide at least a sound technical backing for
> discussions going forward.
>
> --Colin
>
>
> Floodlight: (packages => modules => interfaces exported)
> net.floodlightcontroller.core
> OFMessageFilterManager
> IOFMessageFilterManagerService
> FloodlightProvider/Controller
> IFloodlightProviderService
> net.floodlightcontroller.counter
> CounterStore
> ICounterStoreService
> NullCounterStore
> ICounterStoreService
> net.floodlightcontroller.devicemanager.internal
> DefaultEntityClassifier
> IEntityClassifierService
> DeviceManagerImpl
> IDeviceService
> net.floodlightcontroller.firewall
> Firewall
> IFirewallService
> net.floodlightcontroller.flowcache
> FlowCache
> IFlowCacheService
> FlowReconcileManager
> IFlowReconcileService
> PortDownReconciliation
> (none)
> net.floodlightcontroller.forwarding
> Forwarding
> (none)
> net.floodlightcontroller.hub
> Hub
> (none)
> net.floodlightcontroller.jython
> JythonDebugInterface
> (none)
> net.floodlightcontroller.learningswitch
> LearningSwitch
> ILearningSwitchService
> net.floodlightcontroller.linkdiscovery.internal
> LinkDiscoveryManager
> ILinkDiscoveryService
> net.floodlightcontroller.loadbalancer
> LoadBalancer
> ILoadBalancerService
> net.floodlightcontroller.perfmon
> NullPktInProcessingTime
> IPktInProcessingTimeService
> PktInProcessingTime
> IPktInProcessingTimeService
> net.floodlightcontroller.restserver
> RestApiServer
> IRestApiService
> net.floodlightcontroller.staticflowentry
> StaticFlowEntryPusher
> IStaticFlowEntryPusherService
> net.floodlightcontroller.storage
> AbstractStorageSource
> IStorageSourceService
> NoSqlStorageSource
> IStorageSourceService
> net.floodlightcontroller.threadpool
> ThreadPool
> IThreadPoolService
> net.floodlightcontroller.topology
> TopologyManager
> ITopologyService
> IRoutingService
> net.floodlightcontroller.ui.web
> StaticWebRoutable
> (none)
> net.floodlightcontroller.virtualnetwork
> VirtualNetworkFilter
> IVirtualNetworkService
>
> Daylight: (packages/bundles => interfaces exported)
> org.opendaylight.controller.arphandler.internal
> IHostFinder
> IListenDataPacket
> org.opendaylight.controller.clustering.services_implementation.internal
> IClusterContainerServices
> IClusterServices
> IClusterGlobalServices
> org.opendaylight.controller.clustering.stub.internal
> IClusterContainerServices
> IClusterGlobalServices
> org.opendaylight.controller.configuration.internal
> IConfigurationService
> IConfigurationContainerService
> IConfigurationAware
> org.opendaylight.controller.containermanager.internal
> IContainerManager
> IContainer
> org.opendaylight.controller.forwarding.staticrouting.internal
> IForwardingStaticRouting
> ICacheUpdateAware
> IfNewHostNotify
> IConfigurationContainerAware
> org.opendaylight.controller.forwardingrulesmanager.internal
> IContainerListener
> ISwitchManagerAware
> IForwardingRulesManager
> IInventoryListener
> ICacheUpdateAware
> IConfigurationContainerAware
> IFlowProgrammerListener
> org.opendaylight.controller.hosttracker.internal
> ISwitchManagerAware
> IInventoryListener
> IfIptoHost
> IfHostListener
> ITopologyManagerAware
> org.opendaylight.controller.protocol_plugin.openflow.internal
> IContainerListener
> IController
> IDataPacketListen
> IDataPacketMux
> IDiscoveryService
> IFlowProgrammerNotifier
> IInventoryShimExternalListener
> IMessageListener
> IOFStatisticsManager
> IPluginInDataPacketService
> IPluginInFlowProgrammerService
> IPluginInInventoryService
> IPluginInReadService
> IPluginInTopologyService
> IPluginReadServiceFilter
> IRefreshInternalProvider
> IStatisticsListener
> ITopologyServiceShimListener
> org.opendaylight.controller.protocol_plugins.stub.internal
> IPluginInReadService
> org.opendaylight.controller.routing.dijkstra_implementation.internal
> ITopologyManagerAware
> IRouting
> org.opendaylight.controller.sal.implementation.internal
> IReadService
> IPluginOutTopologyService
> ITopologyService
> IInventoryService
> IPluginOutInventoryService
> IFlowProgrammerService
> IPluginOutFlowProgrammerService
> IPluginOutDataPacketService
> IDataPacketService
> org.opendaylight.controller.samples.loadbalancer.internal
> IListenDataPacket
> IConfigManager
> org.opendaylight.controller.samples.simpleforwarding.internal
> IInventoryListener
> IfNewHostNotify
> IListenRoutingUpdates
> org.opendaylight.controller.statisticsmanager.internal
> IStatisticsManager
> org.opendaylight.controller.switchmanager.internal
> IListenInventoryUpdates
> ISwitchManager
> ICacheUpdateAware
> IConfigurationContainerAware
> org.opendaylight.controller.topologymanager.internal
> IListenTopoUpdates
> ITopologyManager
> IConfigurationContainerAware
> org.opendaylight.controller.usermanager.internal
> ICacheUpdateAware
> IUserManager
> IConfigurationAware_______________________________________________
> Discuss mailing list
> Discuss@...
> https://lists.opendaylight.org/mailman/listinfo/discuss


David Erickson <derickso@...>
 

Thanks Colin!

On 04/29/2013 12:23 PM, Colin Dixon wrote:
Hi Everyone,

Here's a first cut at a list of the modules/bundles in each controller
and the interfaces they export. I used the version of Floodlight that is
available on github rather than the current net-virt-platform code base
because that's what I had loaded up in Eclipse when I started this
process. Obviously, there are going to be some changes, but I think they
are minor.

Throughout the mail I'll use Floodlight to refer to the Floodlight code
base and Daylight to refer to the controller project currently hosted on
the OpenDaylight git repositories. Hopefully, this will simplify the
discussion.

After playing around for a while I generated this list by searching for
implementations of
net.floodlightcontroller.core.module.IFloodlightModule.getModuleServices()
in Floodlight and all calls to
org.osgi.framework.ServiceRegistration.Component.setInterface() in the
Daylight code. Note that there are two implementations of the second
function: one that takes a single interface and one that takes a list.

I classified the Floodlight code into a hierarchy of package => module
=> interface since that was pretty easy. I classified the Daylight code
into a hierarchy of package/bundle => interface. In practice, I think
that there's a 1:1 correspondence between packages and bundles in the
Daylight code, so that's fine. However, there is no real notion of a
"module" in Daylight which is easy to pull out. The result is that I can
really only get per-bundle information.

In reality, it seems like there's something of a concept of a module in
the Daylight code, but it's weakly codified. Basically, in
implementations of
org.opendaylight.controller.sal.core.ComponentActivatorAbstractBase.configureInstance()
and
org.opendaylight.controller.sal.core.ComponentActivatorAbstractBase.configureGlobalInstance(),
they pass the particular implementation being activated and based on
that they change the interfaces. In some cases, the package/bundle only
has one such expected implementation and thus they don't ever use it. In
other cases it has multiple, which are effectively modules, and it
modifies it's behavior depending on which implementation is passed back.

Hopefully, this will provide at least a sound technical backing for
discussions going forward.

--Colin


Floodlight: (packages => modules => interfaces exported)
net.floodlightcontroller.core
OFMessageFilterManager
IOFMessageFilterManagerService
FloodlightProvider/Controller
IFloodlightProviderService
net.floodlightcontroller.counter
CounterStore
ICounterStoreService
NullCounterStore
ICounterStoreService
net.floodlightcontroller.devicemanager.internal
DefaultEntityClassifier
IEntityClassifierService
DeviceManagerImpl
IDeviceService
net.floodlightcontroller.firewall
Firewall
IFirewallService
net.floodlightcontroller.flowcache
FlowCache
IFlowCacheService
FlowReconcileManager
IFlowReconcileService
PortDownReconciliation
(none)
net.floodlightcontroller.forwarding
Forwarding
(none)
net.floodlightcontroller.hub
Hub
(none)
net.floodlightcontroller.jython
JythonDebugInterface
(none)
net.floodlightcontroller.learningswitch
LearningSwitch
ILearningSwitchService
net.floodlightcontroller.linkdiscovery.internal
LinkDiscoveryManager
ILinkDiscoveryService
net.floodlightcontroller.loadbalancer
LoadBalancer
ILoadBalancerService
net.floodlightcontroller.perfmon
NullPktInProcessingTime
IPktInProcessingTimeService
PktInProcessingTime
IPktInProcessingTimeService
net.floodlightcontroller.restserver
RestApiServer
IRestApiService
net.floodlightcontroller.staticflowentry
StaticFlowEntryPusher
IStaticFlowEntryPusherService
net.floodlightcontroller.storage
AbstractStorageSource
IStorageSourceService
NoSqlStorageSource
IStorageSourceService
net.floodlightcontroller.threadpool
ThreadPool
IThreadPoolService
net.floodlightcontroller.topology
TopologyManager
ITopologyService
IRoutingService
net.floodlightcontroller.ui.web
StaticWebRoutable
(none)
net.floodlightcontroller.virtualnetwork
VirtualNetworkFilter
IVirtualNetworkService

Daylight: (packages/bundles => interfaces exported)
org.opendaylight.controller.arphandler.internal
IHostFinder
IListenDataPacket
org.opendaylight.controller.clustering.services_implementation.internal
IClusterContainerServices
IClusterServices
IClusterGlobalServices
org.opendaylight.controller.clustering.stub.internal
IClusterContainerServices
IClusterGlobalServices
org.opendaylight.controller.configuration.internal
IConfigurationService
IConfigurationContainerService
IConfigurationAware
org.opendaylight.controller.containermanager.internal
IContainerManager
IContainer
org.opendaylight.controller.forwarding.staticrouting.internal
IForwardingStaticRouting
ICacheUpdateAware
IfNewHostNotify
IConfigurationContainerAware
org.opendaylight.controller.forwardingrulesmanager.internal
IContainerListener
ISwitchManagerAware
IForwardingRulesManager
IInventoryListener
ICacheUpdateAware
IConfigurationContainerAware
IFlowProgrammerListener
org.opendaylight.controller.hosttracker.internal
ISwitchManagerAware
IInventoryListener
IfIptoHost
IfHostListener
ITopologyManagerAware
org.opendaylight.controller.protocol_plugin.openflow.internal
IContainerListener
IController
IDataPacketListen
IDataPacketMux
IDiscoveryService
IFlowProgrammerNotifier
IInventoryShimExternalListener
IMessageListener
IOFStatisticsManager
IPluginInDataPacketService
IPluginInFlowProgrammerService
IPluginInInventoryService
IPluginInReadService
IPluginInTopologyService
IPluginReadServiceFilter
IRefreshInternalProvider
IStatisticsListener
ITopologyServiceShimListener
org.opendaylight.controller.protocol_plugins.stub.internal
IPluginInReadService
org.opendaylight.controller.routing.dijkstra_implementation.internal
ITopologyManagerAware
IRouting
org.opendaylight.controller.sal.implementation.internal
IReadService
IPluginOutTopologyService
ITopologyService
IInventoryService
IPluginOutInventoryService
IFlowProgrammerService
IPluginOutFlowProgrammerService
IPluginOutDataPacketService
IDataPacketService
org.opendaylight.controller.samples.loadbalancer.internal
IListenDataPacket
IConfigManager
org.opendaylight.controller.samples.simpleforwarding.internal
IInventoryListener
IfNewHostNotify
IListenRoutingUpdates
org.opendaylight.controller.statisticsmanager.internal
IStatisticsManager
org.opendaylight.controller.switchmanager.internal
IListenInventoryUpdates
ISwitchManager
ICacheUpdateAware
IConfigurationContainerAware
org.opendaylight.controller.topologymanager.internal
IListenTopoUpdates
ITopologyManager
IConfigurationContainerAware
org.opendaylight.controller.usermanager.internal
ICacheUpdateAware
IUserManager
IConfigurationAware


David Erickson <daviderickson@...>
 

I went through the Net Virt Platform (more relevant now than Floodlight) and created a similar list of Modules and Interfaces exported by them. I took a wack at putting the data in a table to also include some basic description next to each piece, and put in just a couple of descriptions myself so far (more to come). I think ultimately it would be nice to have a big table that compares all functional pieces from each controller side by side to align where there is similar overlap, and then unique rows where one has something distinct from the other. But to get to that point both need a solid description of the contents.

-David

On 4/29/2013 12:57 PM, David Erickson wrote:
Thanks Colin!

On 04/29/2013 12:23 PM, Colin Dixon wrote:
Hi Everyone,

Here's a first cut at a list of the modules/bundles in each controller
and the interfaces they export. I used the version of Floodlight that is
available on github rather than the current net-virt-platform code base
because that's what I had loaded up in Eclipse when I started this
process. Obviously, there are going to be some changes, but I think they
are minor.

Throughout the mail I'll use Floodlight to refer to the Floodlight code
base and Daylight to refer to the controller project currently hosted on
the OpenDaylight git repositories. Hopefully, this will simplify the
discussion.

After playing around for a while I generated this list by searching for
implementations of
net.floodlightcontroller.core.module.IFloodlightModule.getModuleServices()
in Floodlight and all calls to
org.osgi.framework.ServiceRegistration.Component.setInterface() in the
Daylight code. Note that there are two implementations of the second
function: one that takes a single interface and one that takes a list.

I classified the Floodlight code into a hierarchy of package => module
=> interface since that was pretty easy. I classified the Daylight code
into a hierarchy of package/bundle => interface. In practice, I think
that there's a 1:1 correspondence between packages and bundles in the
Daylight code, so that's fine. However, there is no real notion of a
"module" in Daylight which is easy to pull out. The result is that I can
really only get per-bundle information.

In reality, it seems like there's something of a concept of a module in
the Daylight code, but it's weakly codified. Basically, in
implementations of
org.opendaylight.controller.sal.core.ComponentActivatorAbstractBase.configureInstance()
and
org.opendaylight.controller.sal.core.ComponentActivatorAbstractBase.configureGlobalInstance(),
they pass the particular implementation being activated and based on
that they change the interfaces. In some cases, the package/bundle only
has one such expected implementation and thus they don't ever use it. In
other cases it has multiple, which are effectively modules, and it
modifies it's behavior depending on which implementation is passed back.

Hopefully, this will provide at least a sound technical backing for
discussions going forward.

--Colin


Floodlight: (packages => modules => interfaces exported)
net.floodlightcontroller.core
OFMessageFilterManager
IOFMessageFilterManagerService
FloodlightProvider/Controller
IFloodlightProviderService
net.floodlightcontroller.counter
CounterStore
ICounterStoreService
NullCounterStore
ICounterStoreService
net.floodlightcontroller.devicemanager.internal
DefaultEntityClassifier
IEntityClassifierService
DeviceManagerImpl
IDeviceService
net.floodlightcontroller.firewall
Firewall
IFirewallService
net.floodlightcontroller.flowcache
FlowCache
IFlowCacheService
FlowReconcileManager
IFlowReconcileService
PortDownReconciliation
(none)
net.floodlightcontroller.forwarding
Forwarding
(none)
net.floodlightcontroller.hub
Hub
(none)
net.floodlightcontroller.jython
JythonDebugInterface
(none)
net.floodlightcontroller.learningswitch
LearningSwitch
ILearningSwitchService
net.floodlightcontroller.linkdiscovery.internal
LinkDiscoveryManager
ILinkDiscoveryService
net.floodlightcontroller.loadbalancer
LoadBalancer
ILoadBalancerService
net.floodlightcontroller.perfmon
NullPktInProcessingTime
IPktInProcessingTimeService
PktInProcessingTime
IPktInProcessingTimeService
net.floodlightcontroller.restserver
RestApiServer
IRestApiService
net.floodlightcontroller.staticflowentry
StaticFlowEntryPusher
IStaticFlowEntryPusherService
net.floodlightcontroller.storage
AbstractStorageSource
IStorageSourceService
NoSqlStorageSource
IStorageSourceService
net.floodlightcontroller.threadpool
ThreadPool
IThreadPoolService
net.floodlightcontroller.topology
TopologyManager
ITopologyService
IRoutingService
net.floodlightcontroller.ui.web
StaticWebRoutable
(none)
net.floodlightcontroller.virtualnetwork
VirtualNetworkFilter
IVirtualNetworkService

Daylight: (packages/bundles => interfaces exported)
org.opendaylight.controller.arphandler.internal
IHostFinder
IListenDataPacket
org.opendaylight.controller.clustering.services_implementation.internal
IClusterContainerServices
IClusterServices
IClusterGlobalServices
org.opendaylight.controller.clustering.stub.internal
IClusterContainerServices
IClusterGlobalServices
org.opendaylight.controller.configuration.internal
IConfigurationService
IConfigurationContainerService
IConfigurationAware
org.opendaylight.controller.containermanager.internal
IContainerManager
IContainer
org.opendaylight.controller.forwarding.staticrouting.internal
IForwardingStaticRouting
ICacheUpdateAware
IfNewHostNotify
IConfigurationContainerAware
org.opendaylight.controller.forwardingrulesmanager.internal
IContainerListener
ISwitchManagerAware
IForwardingRulesManager
IInventoryListener
ICacheUpdateAware
IConfigurationContainerAware
IFlowProgrammerListener
org.opendaylight.controller.hosttracker.internal
ISwitchManagerAware
IInventoryListener
IfIptoHost
IfHostListener
ITopologyManagerAware
org.opendaylight.controller.protocol_plugin.openflow.internal
IContainerListener
IController
IDataPacketListen
IDataPacketMux
IDiscoveryService
IFlowProgrammerNotifier
IInventoryShimExternalListener
IMessageListener
IOFStatisticsManager
IPluginInDataPacketService
IPluginInFlowProgrammerService
IPluginInInventoryService
IPluginInReadService
IPluginInTopologyService
IPluginReadServiceFilter
IRefreshInternalProvider
IStatisticsListener
ITopologyServiceShimListener
org.opendaylight.controller.protocol_plugins.stub.internal
IPluginInReadService
org.opendaylight.controller.routing.dijkstra_implementation.internal
ITopologyManagerAware
IRouting
org.opendaylight.controller.sal.implementation.internal
IReadService
IPluginOutTopologyService
ITopologyService
IInventoryService
IPluginOutInventoryService
IFlowProgrammerService
IPluginOutFlowProgrammerService
IPluginOutDataPacketService
IDataPacketService
org.opendaylight.controller.samples.loadbalancer.internal
IListenDataPacket
IConfigManager
org.opendaylight.controller.samples.simpleforwarding.internal
IInventoryListener
IfNewHostNotify
IListenRoutingUpdates
org.opendaylight.controller.statisticsmanager.internal
IStatisticsManager
org.opendaylight.controller.switchmanager.internal
IListenInventoryUpdates
ISwitchManager
ICacheUpdateAware
IConfigurationContainerAware
org.opendaylight.controller.topologymanager.internal
IListenTopoUpdates
ITopologyManager
IConfigurationContainerAware
org.opendaylight.controller.usermanager.internal
ICacheUpdateAware
IUserManager
IConfigurationAware


David Meyer <dmm@...>
 

Thanks David!

--dmm


On Tue, Apr 30, 2013 at 1:23 AM, David Erickson <daviderickson@...> wrote:
I went through the Net Virt Platform (more relevant now than Floodlight) and created a similar list of Modules and Interfaces exported by them.  I took a wack at putting the data in a table to also include some basic description next to each piece, and put in just a couple of descriptions myself so far (more to come).  I think ultimately it would be nice to have a big table that compares all functional pieces from each controller side by side to align where there is similar overlap, and then unique rows where one has something distinct from the other.  But to get to that point both need a solid description of the contents.

-David


On 4/29/2013 12:57 PM, David Erickson wrote:
Thanks Colin!

On 04/29/2013 12:23 PM, Colin Dixon wrote:
Hi Everyone,

Here's a first cut at a list of the modules/bundles in each controller
and the interfaces they export. I used the version of Floodlight that is
available on github rather than the current net-virt-platform code base
because that's what I had loaded up in Eclipse when I started this
process. Obviously, there are going to be some changes, but I think they
are minor.

Throughout the mail I'll use Floodlight to refer to the Floodlight code
base and Daylight to refer to the controller project currently hosted on
the OpenDaylight git repositories. Hopefully, this will simplify the
discussion.

After playing around for a while I generated this list by searching for
implementations of
net.floodlightcontroller.core.module.IFloodlightModule.getModuleServices()
in Floodlight and all calls to
org.osgi.framework.ServiceRegistration.Component.setInterface() in the
Daylight code. Note that there are two implementations of the second
function: one that takes a single interface and one that takes a list.

I classified the Floodlight code into a hierarchy of package => module
=> interface since that was pretty easy. I classified the Daylight code
into a hierarchy of package/bundle => interface. In practice, I think
that there's a 1:1 correspondence between packages and bundles in the
Daylight code, so that's fine. However, there is no real notion of a
"module" in Daylight which is easy to pull out. The result is that I can
really only get per-bundle information.

In reality, it seems like there's something of a concept of a module in
the Daylight code, but it's weakly codified. Basically, in
implementations of
org.opendaylight.controller.sal.core.ComponentActivatorAbstractBase.configureInstance()
and
org.opendaylight.controller.sal.core.ComponentActivatorAbstractBase.configureGlobalInstance(),
they pass the particular implementation being activated and based on
that they change the interfaces. In some cases, the package/bundle only
has one such expected implementation and thus they don't ever use it. In
other cases it has multiple, which are effectively modules, and it
modifies it's behavior depending on which implementation is passed back.

Hopefully, this will provide at least a sound technical backing for
discussions going forward.

--Colin


Floodlight: (packages => modules => interfaces exported)
net.floodlightcontroller.core
OFMessageFilterManager
IOFMessageFilterManagerService
FloodlightProvider/Controller
IFloodlightProviderService
net.floodlightcontroller.counter
CounterStore
ICounterStoreService
NullCounterStore
ICounterStoreService
net.floodlightcontroller.devicemanager.internal
DefaultEntityClassifier
IEntityClassifierService
DeviceManagerImpl
IDeviceService
net.floodlightcontroller.firewall
Firewall
IFirewallService
net.floodlightcontroller.flowcache
FlowCache
IFlowCacheService
FlowReconcileManager
IFlowReconcileService
PortDownReconciliation
(none)
net.floodlightcontroller.forwarding
Forwarding
(none)
net.floodlightcontroller.hub
Hub
(none)
net.floodlightcontroller.jython
JythonDebugInterface
(none)
net.floodlightcontroller.learningswitch
LearningSwitch
ILearningSwitchService
net.floodlightcontroller.linkdiscovery.internal
LinkDiscoveryManager
ILinkDiscoveryService
net.floodlightcontroller.loadbalancer
LoadBalancer
ILoadBalancerService
net.floodlightcontroller.perfmon
NullPktInProcessingTime
IPktInProcessingTimeService
PktInProcessingTime
IPktInProcessingTimeService
net.floodlightcontroller.restserver
RestApiServer
IRestApiService
net.floodlightcontroller.staticflowentry
StaticFlowEntryPusher
IStaticFlowEntryPusherService
net.floodlightcontroller.storage
AbstractStorageSource
IStorageSourceService
NoSqlStorageSource
IStorageSourceService
net.floodlightcontroller.threadpool
ThreadPool
IThreadPoolService
net.floodlightcontroller.topology
TopologyManager
ITopologyService
IRoutingService
net.floodlightcontroller.ui.web
StaticWebRoutable
(none)
net.floodlightcontroller.virtualnetwork
VirtualNetworkFilter
IVirtualNetworkService

Daylight: (packages/bundles => interfaces exported)
org.opendaylight.controller.arphandler.internal
IHostFinder
IListenDataPacket
org.opendaylight.controller.clustering.services_implementation.internal
IClusterContainerServices
IClusterServices
IClusterGlobalServices
org.opendaylight.controller.clustering.stub.internal
IClusterContainerServices
IClusterGlobalServices
org.opendaylight.controller.configuration.internal
IConfigurationService
IConfigurationContainerService
IConfigurationAware
org.opendaylight.controller.containermanager.internal
IContainerManager
IContainer
org.opendaylight.controller.forwarding.staticrouting.internal
IForwardingStaticRouting
ICacheUpdateAware
IfNewHostNotify
IConfigurationContainerAware
org.opendaylight.controller.forwardingrulesmanager.internal
IContainerListener
ISwitchManagerAware
IForwardingRulesManager
IInventoryListener
ICacheUpdateAware
IConfigurationContainerAware
IFlowProgrammerListener
org.opendaylight.controller.hosttracker.internal
ISwitchManagerAware
IInventoryListener
IfIptoHost
IfHostListener
ITopologyManagerAware
org.opendaylight.controller.protocol_plugin.openflow.internal
IContainerListener
IController
IDataPacketListen
IDataPacketMux
IDiscoveryService
IFlowProgrammerNotifier
IInventoryShimExternalListener
IMessageListener
IOFStatisticsManager
IPluginInDataPacketService
IPluginInFlowProgrammerService
IPluginInInventoryService
IPluginInReadService
IPluginInTopologyService
IPluginReadServiceFilter
IRefreshInternalProvider
IStatisticsListener
ITopologyServiceShimListener
org.opendaylight.controller.protocol_plugins.stub.internal
IPluginInReadService
org.opendaylight.controller.routing.dijkstra_implementation.internal
ITopologyManagerAware
IRouting
org.opendaylight.controller.sal.implementation.internal
IReadService
IPluginOutTopologyService
ITopologyService
IInventoryService
IPluginOutInventoryService
IFlowProgrammerService
IPluginOutFlowProgrammerService
IPluginOutDataPacketService
IDataPacketService
org.opendaylight.controller.samples.loadbalancer.internal
IListenDataPacket
IConfigManager
org.opendaylight.controller.samples.simpleforwarding.internal
IInventoryListener
IfNewHostNotify
IListenRoutingUpdates
org.opendaylight.controller.statisticsmanager.internal
IStatisticsManager
org.opendaylight.controller.switchmanager.internal
IListenInventoryUpdates
ISwitchManager
ICacheUpdateAware
IConfigurationContainerAware
org.opendaylight.controller.topologymanager.internal
IListenTopoUpdates
ITopologyManager
IConfigurationContainerAware
org.opendaylight.controller.usermanager.internal
ICacheUpdateAware
IUserManager
IConfigurationAware



_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss


Colin Dixon <ckd@...>
 

Thanks! That's really helpful.

I went through and converted the OpenDaylight Controller information into the same format and tried to clean up some of the text at the top of the wiki page to accurately describe what's presented and how it was generated.

Along the lines of Dave Erickson's comments below, the next step is to try to flesh some of this out with descriptions and other information. It would be even more awesome if we could have the class/interface/package names link to the appropriate place in the javadoc, but I'm not quire sure the best way to do that, maybe others have suggestions.

--Colin

David Erickson <daviderickson@...> wrote on 04/30/2013 03:23:38 AM:
> From: David Erickson <daviderickson@...>

> To: Colin Dixon/Austin/IBM@IBMUS
> Cc: discuss@...
> Date: 04/30/2013 03:25 AM
> Subject: Re: the modules/bundles and exported interfaces of the two code bases
>
> I went through the Net Virt Platform (more relevant now than Floodlight)
> and created a similar list of Modules and Interfaces exported by them.  
> I took a wack at putting the data in a table to also include some basic
> description next to each piece, and put in just a couple of descriptions
> myself so far (more to come).  I think ultimately it would be nice to
> have a big table that compares all functional pieces from each
> controller side by side to align where there is similar overlap, and
> then unique rows where one has something distinct from the other.  But
> to get to that point both need a solid description of the contents.
>
> -David
>
> On 4/29/2013 12:57 PM, David Erickson wrote:
> > Thanks Colin!
> >
> > On 04/29/2013 12:23 PM, Colin Dixon wrote:
> >> Hi Everyone,
> >>
> >> Here's a first cut at a list of the modules/bundles in each controller
> >> and the interfaces they export. I used the version of Floodlight that is
> >> available on github rather than the current net-virt-platform code base
> >> because that's what I had loaded up in Eclipse when I started this
> >> process. Obviously, there are going to be some changes, but I think they
> >> are minor.
> >>
> >> Throughout the mail I'll use Floodlight to refer to the Floodlight code
> >> base and Daylight to refer to the controller project currently hosted on
> >> the OpenDaylight git repositories. Hopefully, this will simplify the
> >> discussion.
> >>
> >> After playing around for a while I generated this list by searching for
> >> implementations of
> >> net.floodlightcontroller.core.module.IFloodlightModule.getModuleServices()
> >>
> >> in Floodlight and all calls to
> >> org.osgi.framework.ServiceRegistration.Component.setInterface() in the
> >> Daylight code. Note that there are two implementations of the second
> >> function: one that takes a single interface and one that takes a list.
> >>
> >> I classified the Floodlight code into a hierarchy of package => module
> >> => interface since that was pretty easy. I classified the Daylight code
> >> into a hierarchy of package/bundle => interface. In practice, I think
> >> that there's a 1:1 correspondence between packages and bundles in the
> >> Daylight code, so that's fine. However, there is no real notion of a
> >> "module" in Daylight which is easy to pull out. The result is that I can
> >> really only get per-bundle information.
> >>
> >> In reality, it seems like there's something of a concept of a module in
> >> the Daylight code, but it's weakly codified. Basically, in
> >> implementations of
> >>
> org.opendaylight.controller.sal.core.ComponentActivatorAbstractBase.configureInstance
> ()
> >>
> >> and
> >>
> org.opendaylight.controller.sal.core.ComponentActivatorAbstractBase.configureGlobalInstance
> (),
> >>
> >> they pass the particular implementation being activated and based on
> >> that they change the interfaces. In some cases, the package/bundle only
> >> has one such expected implementation and thus they don't ever use it. In
> >> other cases it has multiple, which are effectively modules, and it
> >> modifies it's behavior depending on which implementation is passed back.
> >>
> >> Hopefully, this will provide at least a sound technical backing for
> >> discussions going forward.
> >>
> >> --Colin
> >>
> >>
> >> Floodlight: (packages => modules => interfaces exported)
> >> net.floodlightcontroller.core
> >> OFMessageFilterManager
> >> IOFMessageFilterManagerService
> >> FloodlightProvider/Controller
> >> IFloodlightProviderService
> >> net.floodlightcontroller.counter
> >> CounterStore
> >> ICounterStoreService
> >> NullCounterStore
> >> ICounterStoreService
> >> net.floodlightcontroller.devicemanager.internal
> >> DefaultEntityClassifier
> >> IEntityClassifierService
> >> DeviceManagerImpl
> >> IDeviceService
> >> net.floodlightcontroller.firewall
> >> Firewall
> >> IFirewallService
> >> net.floodlightcontroller.flowcache
> >> FlowCache
> >> IFlowCacheService
> >> FlowReconcileManager
> >> IFlowReconcileService
> >> PortDownReconciliation
> >> (none)
> >> net.floodlightcontroller.forwarding
> >> Forwarding
> >> (none)
> >> net.floodlightcontroller.hub
> >> Hub
> >> (none)
> >> net.floodlightcontroller.jython
> >> JythonDebugInterface
> >> (none)
> >> net.floodlightcontroller.learningswitch
> >> LearningSwitch
> >> ILearningSwitchService
> >> net.floodlightcontroller.linkdiscovery.internal
> >> LinkDiscoveryManager
> >> ILinkDiscoveryService
> >> net.floodlightcontroller.loadbalancer
> >> LoadBalancer
> >> ILoadBalancerService
> >> net.floodlightcontroller.perfmon
> >> NullPktInProcessingTime
> >> IPktInProcessingTimeService
> >> PktInProcessingTime
> >> IPktInProcessingTimeService
> >> net.floodlightcontroller.restserver
> >> RestApiServer
> >> IRestApiService
> >> net.floodlightcontroller.staticflowentry
> >> StaticFlowEntryPusher
> >> IStaticFlowEntryPusherService
> >> net.floodlightcontroller.storage
> >> AbstractStorageSource
> >> IStorageSourceService
> >> NoSqlStorageSource
> >> IStorageSourceService
> >> net.floodlightcontroller.threadpool
> >> ThreadPool
> >> IThreadPoolService
> >> net.floodlightcontroller.topology
> >> TopologyManager
> >> ITopologyService
> >> IRoutingService
> >> net.floodlightcontroller.ui.web
> >> StaticWebRoutable
> >> (none)
> >> net.floodlightcontroller.virtualnetwork
> >> VirtualNetworkFilter
> >> IVirtualNetworkService
> >>
> >> Daylight: (packages/bundles => interfaces exported)
> >> org.opendaylight.controller.arphandler.internal
> >> IHostFinder
> >> IListenDataPacket
> >> org.opendaylight.controller.clustering.services_implementation.internal
> >> IClusterContainerServices
> >> IClusterServices
> >> IClusterGlobalServices
> >> org.opendaylight.controller.clustering.stub.internal
> >> IClusterContainerServices
> >> IClusterGlobalServices
> >> org.opendaylight.controller.configuration.internal
> >> IConfigurationService
> >> IConfigurationContainerService
> >> IConfigurationAware
> >> org.opendaylight.controller.containermanager.internal
> >> IContainerManager
> >> IContainer
> >> org.opendaylight.controller.forwarding.staticrouting.internal
> >> IForwardingStaticRouting
> >> ICacheUpdateAware
> >> IfNewHostNotify
> >> IConfigurationContainerAware
> >> org.opendaylight.controller.forwardingrulesmanager.internal
> >> IContainerListener
> >> ISwitchManagerAware
> >> IForwardingRulesManager
> >> IInventoryListener
> >> ICacheUpdateAware
> >> IConfigurationContainerAware
> >> IFlowProgrammerListener
> >> org.opendaylight.controller.hosttracker.internal
> >> ISwitchManagerAware
> >> IInventoryListener
> >> IfIptoHost
> >> IfHostListener
> >> ITopologyManagerAware
> >> org.opendaylight.controller.protocol_plugin.openflow.internal
> >> IContainerListener
> >> IController
> >> IDataPacketListen
> >> IDataPacketMux
> >> IDiscoveryService
> >> IFlowProgrammerNotifier
> >> IInventoryShimExternalListener
> >> IMessageListener
> >> IOFStatisticsManager
> >> IPluginInDataPacketService
> >> IPluginInFlowProgrammerService
> >> IPluginInInventoryService
> >> IPluginInReadService
> >> IPluginInTopologyService
> >> IPluginReadServiceFilter
> >> IRefreshInternalProvider
> >> IStatisticsListener
> >> ITopologyServiceShimListener
> >> org.opendaylight.controller.protocol_plugins.stub.internal
> >> IPluginInReadService
> >> org.opendaylight.controller.routing.dijkstra_implementation.internal
> >> ITopologyManagerAware
> >> IRouting
> >> org.opendaylight.controller.sal.implementation.internal
> >> IReadService
> >> IPluginOutTopologyService
> >> ITopologyService
> >> IInventoryService
> >> IPluginOutInventoryService
> >> IFlowProgrammerService
> >> IPluginOutFlowProgrammerService
> >> IPluginOutDataPacketService
> >> IDataPacketService
> >> org.opendaylight.controller.samples.loadbalancer.internal
> >> IListenDataPacket
> >> IConfigManager
> >> org.opendaylight.controller.samples.simpleforwarding.internal
> >> IInventoryListener
> >> IfNewHostNotify
> >> IListenRoutingUpdates
> >> org.opendaylight.controller.statisticsmanager.internal
> >> IStatisticsManager
> >> org.opendaylight.controller.switchmanager.internal
> >> IListenInventoryUpdates
> >> ISwitchManager
> >> ICacheUpdateAware
> >> IConfigurationContainerAware
> >> org.opendaylight.controller.topologymanager.internal
> >> IListenTopoUpdates
> >> ITopologyManager
> >> IConfigurationContainerAware
> >> org.opendaylight.controller.usermanager.internal
> >> ICacheUpdateAware
> >> IUserManager
> >> IConfigurationAware
> >>
> >
>


Rob Sherwood
 

This is great Dave and Colin -- thanks for jumping on this.  I'm trying to fill in a bunch of the clarifying bits here (and get some other folks to help).  Thanks for getting the ball rolling on this.

- Rob
.


On Tue, Apr 30, 2013 at 11:15 AM, Colin Dixon <ckd@...> wrote:

Thanks! That's really helpful.

I went through and converted the OpenDaylight Controller information into the same format and tried to clean up some of the text at the top of the wiki page to accurately describe what's presented and how it was generated.

Along the lines of Dave Erickson's comments below, the next step is to try to flesh some of this out with descriptions and other information. It would be even more awesome if we could have the class/interface/package names link to the appropriate place in the javadoc, but I'm not quire sure the best way to do that, maybe others have suggestions.

--Colin

David Erickson <daviderickson@...> wrote on 04/30/2013 03:23:38 AM:
> From: David Erickson <daviderickson@...>

> To: Colin Dixon/Austin/IBM@IBMUS
> Cc: discuss@...
> Date: 04/30/2013 03:25 AM
> Subject: Re: the modules/bundles and exported interfaces of the two code bases


>
> I went through the Net Virt Platform (more relevant now than Floodlight)
> and created a similar list of Modules and Interfaces exported by them.  
> I took a wack at putting the data in a table to also include some basic
> description next to each piece, and put in just a couple of descriptions
> myself so far (more to come).  I think ultimately it would be nice to
> have a big table that compares all functional pieces from each
> controller side by side to align where there is similar overlap, and
> then unique rows where one has something distinct from the other.  But
> to get to that point both need a solid description of the contents.
>
> -David
>
> On 4/29/2013 12:57 PM, David Erickson wrote:
> > Thanks Colin!
> >
> > On 04/29/2013 12:23 PM, Colin Dixon wrote:
> >> Hi Everyone,
> >>
> >> Here's a first cut at a list of the modules/bundles in each controller
> >> and the interfaces they export. I used the version of Floodlight that is
> >> available on github rather than the current net-virt-platform code base
> >> because that's what I had loaded up in Eclipse when I started this
> >> process. Obviously, there are going to be some changes, but I think they
> >> are minor.
> >>
> >> Throughout the mail I'll use Floodlight to refer to the Floodlight code
> >> base and Daylight to refer to the controller project currently hosted on
> >> the OpenDaylight git repositories. Hopefully, this will simplify the
> >> discussion.
> >>
> >> After playing around for a while I generated this list by searching for
> >> implementations of
> >> net.floodlightcontroller.core.module.IFloodlightModule.getModuleServices()
> >>
> >> in Floodlight and all calls to
> >> org.osgi.framework.ServiceRegistration.Component.setInterface() in the
> >> Daylight code. Note that there are two implementations of the second
> >> function: one that takes a single interface and one that takes a list.
> >>
> >> I classified the Floodlight code into a hierarchy of package => module
> >> => interface since that was pretty easy. I classified the Daylight code
> >> into a hierarchy of package/bundle => interface. In practice, I think
> >> that there's a 1:1 correspondence between packages and bundles in the
> >> Daylight code, so that's fine. However, there is no real notion of a
> >> "module" in Daylight which is easy to pull out. The result is that I can
> >> really only get per-bundle information.
> >>
> >> In reality, it seems like there's something of a concept of a module in
> >> the Daylight code, but it's weakly codified. Basically, in
> >> implementations of
> >>
> org.opendaylight.controller.sal.core.ComponentActivatorAbstractBase.configureInstance
> ()
> >>
> >> and
> >>
> org.opendaylight.controller.sal.core.ComponentActivatorAbstractBase.configureGlobalInstance
> (),
> >>
> >> they pass the particular implementation being activated and based on
> >> that they change the interfaces. In some cases, the package/bundle only
> >> has one such expected implementation and thus they don't ever use it. In
> >> other cases it has multiple, which are effectively modules, and it
> >> modifies it's behavior depending on which implementation is passed back.
> >>
> >> Hopefully, this will provide at least a sound technical backing for
> >> discussions going forward.
> >>
> >> --Colin
> >>
> >>
> >> Floodlight: (packages => modules => interfaces exported)
> >> net.floodlightcontroller.core
> >> OFMessageFilterManager
> >> IOFMessageFilterManagerService
> >> FloodlightProvider/Controller
> >> IFloodlightProviderService
> >> net.floodlightcontroller.counter
> >> CounterStore
> >> ICounterStoreService
> >> NullCounterStore
> >> ICounterStoreService
> >> net.floodlightcontroller.devicemanager.internal
> >> DefaultEntityClassifier
> >> IEntityClassifierService
> >> DeviceManagerImpl
> >> IDeviceService
> >> net.floodlightcontroller.firewall
> >> Firewall
> >> IFirewallService
> >> net.floodlightcontroller.flowcache
> >> FlowCache
> >> IFlowCacheService
> >> FlowReconcileManager
> >> IFlowReconcileService
> >> PortDownReconciliation
> >> (none)
> >> net.floodlightcontroller.forwarding
> >> Forwarding
> >> (none)
> >> net.floodlightcontroller.hub
> >> Hub
> >> (none)
> >> net.floodlightcontroller.jython
> >> JythonDebugInterface
> >> (none)
> >> net.floodlightcontroller.learningswitch
> >> LearningSwitch
> >> ILearningSwitchService
> >> net.floodlightcontroller.linkdiscovery.internal
> >> LinkDiscoveryManager
> >> ILinkDiscoveryService
> >> net.floodlightcontroller.loadbalancer
> >> LoadBalancer
> >> ILoadBalancerService
> >> net.floodlightcontroller.perfmon
> >> NullPktInProcessingTime
> >> IPktInProcessingTimeService
> >> PktInProcessingTime
> >> IPktInProcessingTimeService
> >> net.floodlightcontroller.restserver
> >> RestApiServer
> >> IRestApiService
> >> net.floodlightcontroller.staticflowentry
> >> StaticFlowEntryPusher
> >> IStaticFlowEntryPusherService
> >> net.floodlightcontroller.storage
> >> AbstractStorageSource
> >> IStorageSourceService
> >> NoSqlStorageSource
> >> IStorageSourceService
> >> net.floodlightcontroller.threadpool
> >> ThreadPool
> >> IThreadPoolService
> >> net.floodlightcontroller.topology
> >> TopologyManager
> >> ITopologyService
> >> IRoutingService
> >> net.floodlightcontroller.ui.web
> >> StaticWebRoutable
> >> (none)
> >> net.floodlightcontroller.virtualnetwork
> >> VirtualNetworkFilter
> >> IVirtualNetworkService
> >>
> >> Daylight: (packages/bundles => interfaces exported)
> >> org.opendaylight.controller.arphandler.internal
> >> IHostFinder
> >> IListenDataPacket
> >> org.opendaylight.controller.clustering.services_implementation.internal
> >> IClusterContainerServices
> >> IClusterServices
> >> IClusterGlobalServices
> >> org.opendaylight.controller.clustering.stub.internal
> >> IClusterContainerServices
> >> IClusterGlobalServices
> >> org.opendaylight.controller.configuration.internal
> >> IConfigurationService
> >> IConfigurationContainerService
> >> IConfigurationAware
> >> org.opendaylight.controller.containermanager.internal
> >> IContainerManager
> >> IContainer
> >> org.opendaylight.controller.forwarding.staticrouting.internal
> >> IForwardingStaticRouting
> >> ICacheUpdateAware
> >> IfNewHostNotify
> >> IConfigurationContainerAware
> >> org.opendaylight.controller.forwardingrulesmanager.internal
> >> IContainerListener
> >> ISwitchManagerAware
> >> IForwardingRulesManager
> >> IInventoryListener
> >> ICacheUpdateAware
> >> IConfigurationContainerAware
> >> IFlowProgrammerListener
> >> org.opendaylight.controller.hosttracker.internal
> >> ISwitchManagerAware
> >> IInventoryListener
> >> IfIptoHost
> >> IfHostListener
> >> ITopologyManagerAware
> >> org.opendaylight.controller.protocol_plugin.openflow.internal
> >> IContainerListener
> >> IController
> >> IDataPacketListen
> >> IDataPacketMux
> >> IDiscoveryService
> >> IFlowProgrammerNotifier
> >> IInventoryShimExternalListener
> >> IMessageListener
> >> IOFStatisticsManager
> >> IPluginInDataPacketService
> >> IPluginInFlowProgrammerService
> >> IPluginInInventoryService
> >> IPluginInReadService
> >> IPluginInTopologyService
> >> IPluginReadServiceFilter
> >> IRefreshInternalProvider
> >> IStatisticsListener
> >> ITopologyServiceShimListener
> >> org.opendaylight.controller.protocol_plugins.stub.internal
> >> IPluginInReadService
> >> org.opendaylight.controller.routing.dijkstra_implementation.internal
> >> ITopologyManagerAware
> >> IRouting
> >> org.opendaylight.controller.sal.implementation.internal
> >> IReadService
> >> IPluginOutTopologyService
> >> ITopologyService
> >> IInventoryService
> >> IPluginOutInventoryService
> >> IFlowProgrammerService
> >> IPluginOutFlowProgrammerService
> >> IPluginOutDataPacketService
> >> IDataPacketService
> >> org.opendaylight.controller.samples.loadbalancer.internal
> >> IListenDataPacket
> >> IConfigManager
> >> org.opendaylight.controller.samples.simpleforwarding.internal
> >> IInventoryListener
> >> IfNewHostNotify
> >> IListenRoutingUpdates
> >> org.opendaylight.controller.statisticsmanager.internal
> >> IStatisticsManager
> >> org.opendaylight.controller.switchmanager.internal
> >> IListenInventoryUpdates
> >> ISwitchManager
> >> ICacheUpdateAware
> >> IConfigurationContainerAware
> >> org.opendaylight.controller.topologymanager.internal
> >> IListenTopoUpdates
> >> ITopologyManager
> >> IConfigurationContainerAware
> >> org.opendaylight.controller.usermanager.internal
> >> ICacheUpdateAware
> >> IUserManager
> >> IConfigurationAware
> >>
> >
>


_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss