Date
1 - 3 of 3
New Project Proposal for Lithium - Driver Identification and Driver Management
|
Dean, Steve <sdean@...>
We have posted a new project proposal for the Lithium release called “Device Identification and Driver Management”. This project proposal replaces the proposal posted on 10/20/2014 call Device Driver Framework.
https://wiki.opendaylight.org/view/Project_Proposals:Device_Identification_And_Driver_Management
Phil, can we get a spot on the TSC agenda on December 18th for the presentation and Creation Review.
Thanks Steve Dean
|
|
|
|
David Bainbridge <dbainbri.ciena@...>
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 |
|
|
|
Colin Dixon
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. Thanks, --ColinOn Mon, Dec 8, 2014 at 12:52 PM, David Bainbridge <dbainbri.ciena@...> wrote:
|
|
|