17:04:41 <colindixon> #startmeeting md-sal interest
17:04:41 <odl_meetbot> Meeting started Tue Feb 24 17:04:41 2015 UTC.  The chair is colindixon. Information about MeetBot at http://ci.openstack.org/meetbot.html.
17:04:41 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:04:41 <odl_meetbot> The meeting name has been set to 'md_sal_interest'
17:04:51 <colindixon> #topic proposed new project spinouts
17:05:04 <colindixon> #chair tbachman dfarrell07
17:05:04 <odl_meetbot> Current chairs: colindixon dfarrell07 tbachman
17:05:21 * tbachman totally forgot about the meeting!
17:05:22 <colindixon> #link https://wiki.opendaylight.org/view/MD-SAL_Weekly_Call#Agenda the agenda in it’s usual place
17:05:37 <colindixon> #link https://wiki.opendaylight.org/view/Project_Proposals:Netconf the Netconf proposal
17:05:45 <colindixon> #link https://wiki.opendaylight.org/view/Project_Proposals:MD-SAL the MD-SAL proposal
17:06:30 <colindixon> #info 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
17:06:56 <phrobb> Do we want to record this session?
17:07:01 <tbachman> #info rovarga_ says they expect the implementation to be ready when Beryllium begins
17:07:08 <tbachman> colindixon: ^^^ record?
17:07:14 <colindixon> #info 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
17:09:07 <colindixon> #info 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
17:09:12 <colindixon> #topic start slides
17:09:22 <tbachman> start slides?
17:09:26 <colindixon> #undo
17:09:26 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Topic object at 0x19d7bd0>
17:09:38 <colindixon> tbachman: what woud be the right topic to get things going
17:09:41 <tbachman> #topic Architecture Overview
17:09:42 <tbachman> ?
17:09:48 <tbachman> colindixon: good?
17:09:52 <colindixon> #info slides will be posted after the call
17:10:01 <colindixon> tbachman: looks good to me
17:10:26 <tbachman> #info The controller project consists of: karaf base; config subsystem; MD-SAL; Netconf subsytem; RESTCONF; and AD-SAL (deprecated)
17:10:36 <tbachman> #info karaf provides the base runtime for distros
17:10:53 <tbachman> #info karaf also provides packaging of components into features
17:11:09 <colindixon> thanks tbachman you rock
17:11:14 <tbachman> #info The config subsystem provides explicit dependency injection, customizable by operator/deployer of system
17:11:40 <tbachman> #info The config subsystem also provides transactional support for startup, teardown, and reconfiguration of these components and their wiring
17:12:01 <tbachman> #info The MD-SAL provides communication patterns for YANG modeled data and representations of these APIS
17:12:25 <tbachman> #info there are two Java representations of the MD-SAL: DOM, and Binding (bulid exlusively on top of DOM APIs)
17:12:35 <tbachman> #info The NETCONF/RESTCONF are protocol implementations
17:12:46 <tbachman> #info NETCONF provides northbound for config subsystem and MD-SAL
17:13:01 <tbachman> #info NETCONF provides southbound for MD-SAL
17:13:10 <tbachman> #info RESTCONF provides a protocol implementation and REST-like YANG modeled APIs for externa apps
17:13:24 <tbachman> #info jmedved says we’ll need southbound RESTCONF as well
17:13:42 <tbachman> #info ttkacik1 says this will be implemented in the Beryllium time frame
17:13:52 <tbachman> colindixon: thx! ;)
17:14:23 <tbachman> #info colindixon points out the neutron has moved from the controller to its own project, and the AD-SAL is deprecated
17:14:33 <tbachman> #info colindixon asks if the NSFs have moved to the openflowplugin yet
17:14:44 <tbachman> #info ttkacik1 says yes, and it will be in the Lithium time frame
17:15:10 <tbachman> #info colindixon asks if there’s any subsystem that’s not covered
17:16:27 <tbachman> #topic Design and Implementation facts
17:16:56 <tbachman> #info There are already several implementations of the MD-SAL DOM APIs, for example DOMDataBroker:
17:17:23 <colindixon> #info 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
17:17:27 <tbachman> #info There are 5 implementations fo DOMDataBroker: two are tied to in-memory data store (IMDS)
17:17:44 <tbachman> #info The SerializedDOMDataBroker (sal-broker-impl) is one of them
17:17:59 <tbachman> #info The COncurrentDOMDataBroker (clustered-data-store) is another
17:18:12 <tbachman> #info The PingPongDataBroker (sal-broker-impl) is another
17:18:30 <tbachman> #info the NetconfDeviceDataBroker (sal-netconf-conector) is another
17:18:40 <tbachman> #info the AuthzDomDataBroker (aaa project) is the last
17:18:47 <colindixon> tbachman: cry uncle if you need help
17:18:50 <tbachman> lol
17:19:07 * tbachman is always willing to have others jump in ;)
17:19:09 <colindixon> #info NetconfDeviceDataBroker allows for netconf devices to be mounted into the MD-SAL
17:19:24 <colindixon> #info AuthzDomDataBroker is layered in front of another broker to provide authorization
17:19:49 <tbachman> #info rovarga_ says the SNMP project might want to implement a data broker in order to implement a data broker for SNMP-enabled devices
17:20:05 <tbachman> making 6 brokers :)
17:20:36 <tbachman> #info colindixon asks even though it’s a data broker, does it include RPCs as well?
17:21:08 <tbachman> #info The answer is that other brokers need to be used (e.g. RPC broker)
17:21:41 <tbachman> #info colindixon points out you can add an RPC broker, data broker, and notification broker, but not all are required
17:22:00 <tbachman> #info ttkacik1 says SNMP is a special case b/c it has a well-defined mapping from MIB to modules
17:22:17 * tbachman wonders if we’re going back to SNMP…. first class citizen :)
17:22:32 <tbachman> SNMP: the new, new OpenFlow
17:23:22 <tbachman> #info ttkacik1 says that none of the DOM implementations is aware of the Binding MD-SAL implementation
17:23:38 <tbachman> #info ttkacik1 says this makes it possible to run the Binding MD-SAL on top of any implementation
17:24:00 <tbachman> #info Netconf Connector (Netconf mountpoints) are implementation of DOM MD-SAL
17:25:00 <tbachman> #topic Reasons for spin-offs
17:25:54 * djx is thinking if is there a new SNMP that was released in the current days or if tbachman is being funny
17:26:31 <tbachman> djx: they’re just pointing out that if someone wanted to write a broker, you could easily use SNMP
17:26:38 * tbachman isn’t very funny ;)
17:27:08 <tbachman> </joking>
17:27:13 <djx> lol
17:27:18 <tbachman> except about the broker part
17:27:29 <djx> understood
17:27:44 <rovarga_> tbachman: SNMP is a first-class legacy citizen :)
17:27:49 <tbachman> #info controller project is a large codbase, very hard for newcomers
17:28:00 <tbachman> #info very few contributors have in-depth knowledge of all subsystems
17:28:17 <tbachman> #info The current scope of the controller is confusing because of the aforementioned reasons
17:28:43 <tbachman> #info NETCONF/RESTCONF has clear scope boundaries, and both are standardized in the same IETF working group
17:29:24 <tbachman> #info NETCONF/RESTCONF are components that provide external access to the system, so needs support of AAA for real production deployment
17:29:47 <tbachman> #info MD-SAL defines separation of concerns — APIs define how components communicate, what conceptual base functionality is provided
17:29:55 <tbachman> #info This still leaves freedom for implementation
17:30:15 <tbachman> #info separation of MD-SAL APIs will make clear there are different implementations (true since Hydrogen)
17:30:40 <tbachman> #info separation makes clearer what exactly is MD-SAL, and makes all implementations equal
17:30:50 <tbachman> #info Binding MD-SAL could be run on top of any DOM MD-SAL
17:32:16 <tbachman> #topic Questions and Discussion
17:33:45 <tbachman> #info 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
17:33:52 <colindixon> tbachman: thanks!
17:34:06 <tbachman> #info rovarga_ says as far as splitting the bindings, he’s confident the API set will be maintained so that they won’t evolve heavily
17:34:28 <tbachman> #info rovarga_ says those APIs haven’t changed, and therefore feels these are low risk
17:34:50 <tbachman> #info rovarga_ says the binding part needs to be co-evolved for a bit to shake out usability bugs (e.g. no listenable futures)
17:35:03 <tbachman> colindixon: np!
17:35:45 <tbachman> #info rovarga_ says they define new classes when they need to define any new concept, deprecate the old ones
17:36:18 <tbachman> #info 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
17:38:53 <tbachman> #info colindixon says it’s not obvious how this refactoring makes it easier for new folks trying to come up to speed on OpenDaylight
17:39:13 <tbachman> #info colindixon asks how splitting these across multiple projects instead of having them in a single one won’t lead to more confusion
17:39:38 <tbachman> #info rovarga_ says usually you want to use an API or fix an implementation — involves diffferent skill sets
17:39:59 <tbachman> #info rovarga_ says the MD-SAL repo will be watched a lot more, since the APIs would be there
17:40:24 <tbachman> #info rovarga_ says having the APIs and implementations in one project is necesarrily creating first class and second class citizens
17:41:03 <tbachman> #info jmedved says we need to document this well to make this easier for people to understand
17:41:08 <colindixon> #link https://lists.opendaylight.org/pipermail/tsc/2015-February/002568.html mailing list thread on the MD-SAL spinout
17:41:29 <tbachman> #info jmedved sasy it really makes it cleaner to deploy the same design pattern accross projects
17:41:29 <colindixon> #link https://lists.opendaylight.org/pipermail/tsc/2015-February/002545.html maling list thread on the NETCONF/RESTCONF spinout
17:41:34 <tbachman> colindixon: thx!
17:42:36 <tbachman> #info alagalah asks if it’s worth adding the project leads from dependent projects on the reviews
17:42:52 <tbachman> #info rovarga_ says it makes sense, but we need a way to automate this, and have a timeout
17:43:32 <tbachman> #info 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)
17:43:34 <colindixon> #info 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
17:44:08 * tbachman isn’t sure exactly what rovarga_ said there
17:44:35 <colindixon> #info rovarga_ responds to catohornet that having it’s own project may make it easier to prioritize feature requests
17:45:38 <tbachman> #info colindixon asks what are the tradeoffs for separation within a project using subdirs vs. separate projects
17:45:57 <tbachman> #info ttkacik1 says that’s already happening, but doesn’t solve some of the clarity issues
17:46:38 <tbachman> #info ttkacik1 says the controller term is currently confusing to people who are onboarding to ODL
17:46:54 <colindixon> #info 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
17:47:34 <tbachman> #info colindixon asks if the goal is to eventually have the controller project go away, once everything’s been properly factored out
17:47:51 <tbachman> #info rovarga_ says yes, provided things like karaf can be properly factored out
17:48:54 <tbachman> #info edwarnicke says that until we get more folks contributing to karaf other than himself, he’s hesitant to spinning that out of the controller
17:49:06 * tbachman hopes edwarnicke doesn’t decide to run off and join the circus
17:49:24 <edwarnicke> tbachman: I have considered it: https://www.youtube.com/watch?v=z7hwBrl0aeI
17:49:57 <tbachman> edwarnicke: holy moly batman!
17:52:10 <djx> edwarnicke that was scary I thought she was going to fell off
17:53:10 <tbachman> colindixon: it’s not you, it’s me
17:53:31 <tbachman> #action alagalah to bring up active committer issue with TSC
17:53:49 <dfarrell07> ^^maybe s/TSC/TWS?
17:54:06 <tbachman> dfarrell07: ah, k
17:54:13 * tbachman didn’t hear it well
17:54:16 <tbachman> is that what he said?
17:54:24 <tbachman> #undo
17:54:24 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Action object at 0x1babd50>
17:54:38 <dfarrell07> He didn't say directly, but colindixon said TWS and he runs TWS so I assumed TWS
17:54:38 <tbachman> #action alagalah to bring up active committer issue with the community
17:54:46 <dfarrell07> ^^+1
17:54:50 <tbachman> dfarrell07: thx!
17:55:04 <dfarrell07> :)
17:56:53 <tbachman> #info alagalah asks if he heard correctly that NSFs are moving from the controller to the openflowplugin
17:56:58 <tbachman> #info rovarga_ says yes
17:57:14 <tbachman> #info alagalah asks if there is a case where people would want the NSFs w/o the openflowplugin
17:57:49 <tbachman> #info edwarnicke says that the current implementation of NSFs are in the openflowplugin, but they aren’t bound to the openflowplugin
17:58:30 <tbachman> #info alagalah asks if it’s possible to link dependent gerrits, between projects
17:59:18 <tbachman> #info 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)
17:59:58 <tbachman> #info 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
18:00:22 <tbachman> #info rovarga_ asks if topics work across projects in gerrit
18:00:28 <tbachman> #info colindixon says they do work across projects
18:01:03 <tbachman> #info 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)
18:01:33 <tbachman> #info colindixon hasn’t seen how multi-project rollback has been supported in a sane way
18:01:49 <tbachman> #info ttkacik1 says mlemay was trying to use google repotools for cross-project development
18:02:29 <mlemay> Yes ask jfokkan
18:02:33 <tbachman> I have to run
18:03:22 <tbachman> can someone else end the meeting?
18:03:25 <tbachman> I had to leave
18:03:30 <tbachman> (i.e. end it when it’s over)
18:03:56 <colindixon> #endmeeting