My thought process turns this way (and this quickly turns into a meta-discussion on the process):

First, I'm not yet convinced that the only difference between DIDM and Discovery is the mechanism for distribution/routing of RPC and DCN

However, if that is the only difference, then I'm also not sure what process and tools we have for encouraging the new mechanism into the existing discovery project.  Folks willing to contribute code for the DIDM mechanism would require some time before they can become committers on the Discovery project, which begs the question of how the DIDM mechanism would get into the discovery project to begin with.

Finally, I'm not yet comfortable with creating DIDM on the hope that DIDM and Discovery can merge into a single project *someday*.

So, color me looking for ideas on how to cut the gordion knot I'm starting to see...

Ryan

Colin Dixon ---12/09/2014 10:14:21 PM---Looping in the TSC list for discussion. TSC members, depending on the discussion here, we may try to

From: Colin Dixon <colin@...>
To: David Bainbridge <dbainbri.ciena@...>
Cc: "tsc@..." <tsc@...>, "project-proposals@..." <project-proposals@...>
Date: 12/09/2014 10:14 PM
Subject: Re: [OpenDaylight TSC] [Project-proposals] New Project Proposal for Lithium - Driver Identification and Driver Management
Sent by: tsc-bounces@...

I wasn't subscribed to the list when this announcement came through, so this may not find itself in the correct thread, anyway ...

Full disclosure: I have been in several meetings with HP about this project and how / should this project combine with the discovery project that is already in incubation. We were near agreement but came to a bit of a sticking point over a "centralized" vs "decentralized" model which I will detail below.

I think there is significant overlap between this project and the discovery project particularly around the concept of identification of devices. As such I think it would be in the best interest of the community to have a single direction around this. The community should really help drive this. As stated I think we really came to much agreement as a way to implement this except around the centralized v. decentralized area.

My interpretation of the centralized v. decentralized issues is really about utilizing the MD-SAL for RPC routing and data change notifications directly to device support plugins (decentralized) or leveraging a single component that captures data change notifications and then calls RPCs in the device drivers (centralized).

The centralized approach is attractive because it becomes a place where process throttling can be managed, but it also means that plugins would now have to register RPCs to the centralized component as opposed to the MD-SAL. As such the centralized approach becomes a sort of "shadow" SAL and plugin developers now have to decide to either register against this centralized component or against the MD-SAL. This, i think, will lead to confusion and complexities for plugin developers as well as support.

My opinion, would be that this work be combined with the discovery project (perhaps under a new project name and joint leadership), but going forward the implementation uses the MD-SAL and proposes requirements on the MD-SAL where throttling and or filtering is required. This, I think, is in line with the ODL design target and thus will likely fit ODL going forward.

I think the discussions I have had with HP around this project have lead to some implementation changes we are planning for the discovery module which will greatly benefit that project so I am very appreciative of those discussions. 

Just my 2 cents ...

mahalo,
/david




_______________________________________________
project-proposals mailing list
project-proposals@...
https://lists.opendaylight.org/mailman/listinfo/project-proposals