#opendaylight-meeting: md-sal interest

Meeting started by colindixon at 17:04:41 UTC (full logs).

Meeting summary

  1. proposed new project spinouts (colindixon, 17:04:51)
    1. https://wiki.opendaylight.org/view/MD-SAL_Weekly_Call#Agenda the agenda in it’s usual place (colindixon, 17:05:22)
    2. https://wiki.opendaylight.org/view/Project_Proposals:Netconf the Netconf proposal (colindixon, 17:05:37)
    3. https://wiki.opendaylight.org/view/Project_Proposals:MD-SAL the MD-SAL proposal (colindixon, 17:05:45)
    4. Tony (ttkacik1) and Robert (rovarga_) will presen their two proposals on possible spin out projects from the controller (and YANG tools) for the Beryllium time-frame (colindixon, 17:06:30)
    5. rovarga_ says they expect the implementation to be ready when Beryllium begins (tbachman, 17:07:01)
    6. rovarga_ notes that his goal is to have this done by the time Beryllium starts, e.g., in between the Lithium release and the Beryllium open (colindixon, 17:07:14)
    7. edwarnicke notes that the this really means between M5 of Lithium (which is code freeze and cut across to stable-lithium) and the start of Beryllium (colindixon, 17:09:07)

  2. Architecture Overview (tbachman, 17:09:41)
    1. slides will be posted after the call (colindixon, 17:09:52)
    2. The controller project consists of: karaf base; config subsystem; MD-SAL; Netconf subsytem; RESTCONF; and AD-SAL (deprecated) (tbachman, 17:10:26)
    3. karaf provides the base runtime for distros (tbachman, 17:10:36)
    4. karaf also provides packaging of components into features (tbachman, 17:10:53)
    5. The config subsystem provides explicit dependency injection, customizable by operator/deployer of system (tbachman, 17:11:14)
    6. The config subsystem also provides transactional support for startup, teardown, and reconfiguration of these components and their wiring (tbachman, 17:11:40)
    7. The MD-SAL provides communication patterns for YANG modeled data and representations of these APIS (tbachman, 17:12:01)
    8. there are two Java representations of the MD-SAL: DOM, and Binding (bulid exlusively on top of DOM APIs) (tbachman, 17:12:25)
    9. The NETCONF/RESTCONF are protocol implementations (tbachman, 17:12:35)
    10. NETCONF provides northbound for config subsystem and MD-SAL (tbachman, 17:12:46)
    11. NETCONF provides southbound for MD-SAL (tbachman, 17:13:01)
    12. RESTCONF provides a protocol implementation and REST-like YANG modeled APIs for externa apps (tbachman, 17:13:10)
    13. jmedved says we’ll need southbound RESTCONF as well (tbachman, 17:13:24)
    14. ttkacik1 says this will be implemented in the Beryllium time frame (tbachman, 17:13:42)
    15. colindixon points out the neutron has moved from the controller to its own project, and the AD-SAL is deprecated (tbachman, 17:14:23)
    16. colindixon asks if the NSFs have moved to the openflowplugin yet (tbachman, 17:14:33)
    17. ttkacik1 says yes, and it will be in the Lithium time frame (tbachman, 17:14:44)
    18. colindixon asks if there’s any subsystem that’s not covered (tbachman, 17:15:10)

  3. Design and Implementation facts (tbachman, 17:16:27)
    1. There are already several implementations of the MD-SAL DOM APIs, for example DOMDataBroker: (tbachman, 17:16:56)
    2. the sub-parts of the controller project that existed in the Helium release were: AD-SAL (marked as deprecated), NSFs (moved to OF plugin?), Neutron (already a new project), MD-SAL concepts/APIs, MD-SAL implementations (“in memory” and “clustered” implementations), Config subsystem, Netconf (SB, NB, and RESTCONF?), Karaf (colindixon, 17:17:23)
    3. There are 5 implementations fo DOMDataBroker: two are tied to in-memory data store (IMDS) (tbachman, 17:17:27)
    4. The SerializedDOMDataBroker (sal-broker-impl) is one of them (tbachman, 17:17:44)
    5. The COncurrentDOMDataBroker (clustered-data-store) is another (tbachman, 17:17:59)
    6. The PingPongDataBroker (sal-broker-impl) is another (tbachman, 17:18:12)
    7. the NetconfDeviceDataBroker (sal-netconf-conector) is another (tbachman, 17:18:30)
    8. the AuthzDomDataBroker (aaa project) is the last (tbachman, 17:18:40)
    9. NetconfDeviceDataBroker allows for netconf devices to be mounted into the MD-SAL (colindixon, 17:19:09)
    10. AuthzDomDataBroker is layered in front of another broker to provide authorization (colindixon, 17:19:24)
    11. rovarga_ says the SNMP project might want to implement a data broker in order to implement a data broker for SNMP-enabled devices (tbachman, 17:19:49)
    12. colindixon asks even though it’s a data broker, does it include RPCs as well? (tbachman, 17:20:36)
    13. The answer is that other brokers need to be used (e.g. RPC broker) (tbachman, 17:21:08)
    14. colindixon points out you can add an RPC broker, data broker, and notification broker, but not all are required (tbachman, 17:21:41)
    15. ttkacik1 says SNMP is a special case b/c it has a well-defined mapping from MIB to modules (tbachman, 17:22:00)
    16. ttkacik1 says that none of the DOM implementations is aware of the Binding MD-SAL implementation (tbachman, 17:23:22)
    17. ttkacik1 says this makes it possible to run the Binding MD-SAL on top of any implementation (tbachman, 17:23:38)
    18. Netconf Connector (Netconf mountpoints) are implementation of DOM MD-SAL (tbachman, 17:24:00)

  4. Reasons for spin-offs (tbachman, 17:25:00)
    1. controller project is a large codbase, very hard for newcomers (tbachman, 17:27:49)
    2. very few contributors have in-depth knowledge of all subsystems (tbachman, 17:28:00)
    3. The current scope of the controller is confusing because of the aforementioned reasons (tbachman, 17:28:17)
    4. NETCONF/RESTCONF has clear scope boundaries, and both are standardized in the same IETF working group (tbachman, 17:28:43)
    5. NETCONF/RESTCONF are components that provide external access to the system, so needs support of AAA for real production deployment (tbachman, 17:29:24)
    6. MD-SAL defines separation of concerns — APIs define how components communicate, what conceptual base functionality is provided (tbachman, 17:29:47)
    7. This still leaves freedom for implementation (tbachman, 17:29:55)
    8. separation of MD-SAL APIs will make clear there are different implementations (true since Hydrogen) (tbachman, 17:30:15)
    9. separation makes clearer what exactly is MD-SAL, and makes all implementations equal (tbachman, 17:30:40)
    10. Binding MD-SAL could be run on top of any DOM MD-SAL (tbachman, 17:30:50)

  5. Questions and Discussion (tbachman, 17:32:16)
    1. colindixon asks when we had the NSF APIs in the controller and NSF implementations in the openflowplugin, this made applying patches that affect this difficult, as it required committers in both projects to work in sync/tandem — asks how this refactoring can be coordinated to prevent the same problem (tbachman, 17:33:45)
    2. rovarga_ says as far as splitting the bindings, he’s confident the API set will be maintained so that they won’t evolve heavily (tbachman, 17:34:06)
    3. rovarga_ says those APIs haven’t changed, and therefore feels these are low risk (tbachman, 17:34:28)
    4. rovarga_ says the binding part needs to be co-evolved for a bit to shake out usability bugs (e.g. no listenable futures) (tbachman, 17:34:50)
    5. rovarga_ says they define new classes when they need to define any new concept, deprecate the old ones (tbachman, 17:35:45)
    6. rovarga_ says there have been 2-3 iterations of the MD-SAL APIs and feel like splitting the MD-SAL APIs from the implementations will not be an issue (tbachman, 17:36:18)
    7. colindixon says it’s not obvious how this refactoring makes it easier for new folks trying to come up to speed on OpenDaylight (tbachman, 17:38:53)
    8. colindixon asks how splitting these across multiple projects instead of having them in a single one won’t lead to more confusion (tbachman, 17:39:13)
    9. rovarga_ says usually you want to use an API or fix an implementation — involves diffferent skill sets (tbachman, 17:39:38)
    10. rovarga_ says the MD-SAL repo will be watched a lot more, since the APIs would be there (tbachman, 17:39:59)
    11. rovarga_ says having the APIs and implementations in one project is necesarrily creating first class and second class citizens (tbachman, 17:40:24)
    12. jmedved says we need to document this well to make this easier for people to understand (tbachman, 17:41:03)
    13. https://lists.opendaylight.org/pipermail/tsc/2015-February/002568.html mailing list thread on the MD-SAL spinout (colindixon, 17:41:08)
    14. jmedved sasy it really makes it cleaner to deploy the same design pattern accross projects (tbachman, 17:41:29)
    15. https://lists.opendaylight.org/pipermail/tsc/2015-February/002545.html maling list thread on the NETCONF/RESTCONF spinout (colindixon, 17:41:29)
    16. alagalah asks if it’s worth adding the project leads from dependent projects on the reviews (tbachman, 17:42:36)
    17. rovarga_ says it makes sense, but we need a way to automate this, and have a timeout (tbachman, 17:42:52)
    18. catohornet asks how much easier/harder is it to use any southbound device, and will this increase the functionality fo NETCONF (e.g. currently can’t do some things with existing implementation) (tbachman, 17:43:32)
    19. colindixon says he agrees with jmedved that docuemntation (e.g., the architecture and which repos to look at) could help making these changes easier on developers, especicially new ones, but that historically we have not been great at providign that (colindixon, 17:43:34)
    20. rovarga_ responds to catohornet that having it’s own project may make it easier to prioritize feature requests (colindixon, 17:44:35)
    21. colindixon asks what are the tradeoffs for separation within a project using subdirs vs. separate projects (tbachman, 17:45:38)
    22. ttkacik1 says that’s already happening, but doesn’t solve some of the clarity issues (tbachman, 17:45:57)
    23. ttkacik1 says the controller term is currently confusing to people who are onboarding to ODL (tbachman, 17:46:38)
    24. ttkacik1 points out that “controller” is probably a bad name for people looking at things since it implies that it is more than it currently is (colindixon, 17:46:54)
    25. colindixon asks if the goal is to eventually have the controller project go away, once everything’s been properly factored out (tbachman, 17:47:34)
    26. rovarga_ says yes, provided things like karaf can be properly factored out (tbachman, 17:47:51)
    27. edwarnicke says that until we get more folks contributing to karaf other than himself, he’s hesitant to spinning that out of the controller (tbachman, 17:48:54)
    28. ACTION: alagalah to bring up active committer issue with the community (tbachman, 17:54:38)
    29. alagalah asks if he heard correctly that NSFs are moving from the controller to the openflowplugin (tbachman, 17:56:53)
    30. rovarga_ says yes (tbachman, 17:56:58)
    31. alagalah asks if there is a case where people would want the NSFs w/o the openflowplugin (tbachman, 17:57:14)
    32. edwarnicke says that the current implementation of NSFs are in the openflowplugin, but they aren’t bound to the openflowplugin (tbachman, 17:57:49)
    33. alagalah asks if it’s possible to link dependent gerrits, between projects (tbachman, 17:58:30)
    34. colindixon says there is an experimental (or feature request) in gerrit, which partially solves the problem by adding metadata, but doesn’t solve the problem b/c two patches across two projects aren’t atomic (due to the need of dependent artifacts and merge jobs) (tbachman, 17:59:18)
    35. alagalah says this would be helpful on a number of levels — e.g. the models moving would have been nice to have had that linked to gerrits in other projects (tbachman, 17:59:58)
    36. rovarga_ asks if topics work across projects in gerrit (tbachman, 18:00:22)
    37. colindixon says they do work across projects (tbachman, 18:00:28)
    38. colindixon says you could use topics or explicitly mention the other packages in the commit (e.g. git hashes, not gerrit links, which are specific to gerrit) (tbachman, 18:01:03)
    39. colindixon hasn’t seen how multi-project rollback has been supported in a sane way (tbachman, 18:01:33)
    40. ttkacik1 says mlemay was trying to use google repotools for cross-project development (tbachman, 18:01:49)


Meeting ended at 18:03:56 UTC (full logs).

Action items

  1. alagalah to bring up active committer issue with the community


People present (lines said)

  1. tbachman (113)
  2. colindixon (26)
  3. odl_meetbot (6)
  4. djx (4)
  5. dfarrell07 (4)
  6. phrobb (1)
  7. edwarnicke (1)
  8. mlemay (1)
  9. rovarga_ (1)


Generated by MeetBot 0.1.4.