[OpenDaylight TSC] New Project Proposal for Lithium - Driver Identification and Driver Management
Ryan Moats <rmoats@...>
My thought process turns this way (and this quickly turns into a meta-discussion on the process):
Looping in the TSC list for discussion.
TSC members, depending on the discussion here, we may try to have a creation review for this project on Thursday. If there are issues we'd like to see resolved before voting it would be better to know that *before* we spent ~30 minutes on a TSC call only to send it back for further consideration.
On Mon, Dec 8, 2014 at 12:52 PM, David Bainbridge <dbainbri.ciena@...> wrote:
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 ...
project-proposals mailing list
TSC mailing list
|1 - 1 of 1|