On Jan 8, 2015, at 3:11 AM, Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco) <rovarga@...> wrote:

Hello Raghu,

 

I am a bit worried about „protocol-agnostic“ bit, as even if you factor the control protocol out, you have to make assumptions about your model of the world (contrast OF vs. PCEP vs. SR). Generic applications can work only as long as those assumptions hold.

 

FRM is very much OF-specific, as it has the notion of a „flow“, at least now. Given where we are on the Lithium trajectory, we can only do so much.

 

Inventory-manager is completely tied to OF, and the OFP design calls for its complete integration into the OFP pipeline. Realistically, its functionality is tightly coupled with the lifecycle of the underlying protocol (we have fully-integrated equivalents in PCEP and NETCONF, and they work better). With the intetion to deprecate opendaylight-inventory model, the roles of inventory-manager and topology-manager are largely the same (when we disregard the discovery piece, which again is technology-specific).

 

Bye,

Robert

 

 

From: Raghurama Bhat [mailto:raghu.odl@...] 
Sent: Thursday, January 08, 2015 5:58 AM
To: Michal Rehak -X (mirehak - Pantheon Technologies SRO at Cisco); release@...
Cc: openflowplugin-dev; aaa-dev@...; ovsdb-dev@...; groupbasedpolicy-dev@...; affinity-dev@...; l2switch-dev@...; Jan Medved (jmedved); Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco); Ed Warnicke (eaw); Moiz Raja (moraja)
Subject: Re: [L2switch-dev] migration of openflow related modules and applications from controller into ofplugin repo

 

Hi,

 

If there was a discussion on this topic in the community I missed it. I know there is general consensus on moving the non-core parts of the controller from the controller repo to other projects as appropriate but I was hoping there would be a discussion on the specifics of the plan before we execute on it. 

 

Some of these make complete sense to me. For example, All the Openflow related models and OpenFlow specific components like Statistics Manager, and LLDP Discovery certainly belong in the Openflow Plugin project.  

 

However, I think the following  Applications need to be more generic and protocol agnostic although the we only had an Openflow implementation until now.   Or, Are we talking about splitting the functionality of these into Generic Components which implement the Models and the NB Interface and Openflow Specific implementations?

• forwardingrules-manager
• inventory-manager
• topology-manager

Another reason I am bringing it up here is that there was a discussion thread of making L2 Switch project to be the home for generic services like Topology and LLDP Discovery  and potentially renaming it to be more generic to reflect the true nature of its content. 

 

BTW, Does the list below represent the complete  picture of migrations like this or is there more? This might be a good topic for the TWS Call as well.

 

Thoughts?

 

Thanks,

 

—Raghu

 

From: "Michal Rehak -X (mirehak - Pantheon Technologies SRO at Cisco)" <mirehak@...>
Date: Wednesday, January 7, 2015 at 8:09 AM
To: "release@..." <release@...>
Cc: openflowplugin-dev <openflowplugin-dev@...>, "aaa-dev@..." <aaa-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...>, "groupbasedpolicy-dev@..." <groupbasedpolicy-dev@...>, "affinity-dev@..." <affinity-dev@...>, "l2switch-dev@..." <l2switch-dev@...>
Subject: [L2switch-dev] migration of openflow related modules and applications from controller into ofplugin repo

 

Greetings,
there are already some activities going on which are aimed to migrate openflow related models and applications from controller to openflowplugin repository.

Migration will take following steps:

• copy corresponding projects from controller into openflowplugin
• change project and package names where necessary (without changing model content) (deadline: 09.01.2015)
• adapt downstream project in order to use those model projects (deadline: 16.01.2015)
• remove models from controller repository (deadline: 23.01.2015)

Models to migrate:

• model/model-flow-base
• model/model-flow-service
• model/model-flow-statistics

Apps to migrate

• statistics-manager
• forwardingrules-manager
• inventory-manager
• topology-lldp-discovery
• topology-manager

Donwstream projects (so far)

• aaa
• l2switch
• ovsdb
• openflowplugin
• affinity
• packetcable
• grupbasedpolicy

If you have questions, contributions, comments then please feel free to respond.

The reason for models to move into openflowplugin is that those models are openflow specific and mostly driven by openflowplugin development. And controller project plans to go more abstract/general way. 

With applications the situation is similar with one difference - there is no direct downstream project, there are just projects depending on dataStore result of those applications.

 

There are no deadlines for applications yet but moving them together with models might spare us some renaming work.

 

Thank you.

Regards,

Michal

 

 

_______________________________________________ L2switch-dev mailing list L2switch-dev@...https://lists.opendaylight.org/mailman/listinfo/l2switch-dev

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