=================================================== #opendaylight-devforum5: Breaking up the controller =================================================== Meeting started by devinavery at 22:56:26 UTC. The full logs are available at http://meetings.opendaylight.org/opendaylight-devforum5/2014/breaking_up_the_controller/opendaylight-devforum5-breaking_up_the_controller.2014-09-29-22.56.log.html . Meeting summary --------------- * Whats Wrong with the controller? (devinavery, 22:57:04) * takes a long time to build (devinavery, 22:57:06) * - a deep tree makes it hard to find what you are looking for if you have a really deep nested tree (devinavery, 22:57:50) * The names of the maven artifact don't match the folder structure (devinavery, 22:58:20) * Takes a long time to start (devinavery, 22:58:32) * different sub systems in one project allows for relaxed API control (devinavery, 22:59:13) * Lots of functionality that is not always related - so if you make change in part A, you have to rebuild and retest Part Z which is unrelated (devinavery, 23:00:43) * Unused code / dead code (devinavery, 23:01:31) * Huge number of committers that can not always review all code - leads to confusion on the overall direction of the project (devinavery, 23:02:36) * - Question - What belongs in the "controller"? (devinavery, 23:03:36) * Robert V suggest the "controller" is more of a platform for development (devinavery, 23:04:04) * The controller should be a platform which provides "general" services (to be defined) (devinavery, 23:09:02) * One suggestion is that the controller platform should not contain network services models (devinavery, 23:09:32) * One thought - should have very few yang models in it (devinavery, 23:09:44) * Question - why call it a controller if it is not controlling anything? Suggestion we could change the "name"of this project (devinavery, 23:10:00) * If we call it a controller we should control something (devinavery, 23:10:24) * Thought - controller means it controls something - traffic perhaps? (devinavery, 23:11:40) * Platform to provide capabilities to manage the traffic, but not the applications (devinavery, 23:13:19) * What are the sub components? (devinavery, 23:14:54) * AD-SAL Openflow Controller (devinavery, 23:15:02) * AD-SAL clustering infrastructure (devinavery, 23:15:14) * MD-SAL, RESTCONF, clustering (devinavery, 23:15:35) * MD-SAL Extension services (xSql, Sample code) (devinavery, 23:16:04) * Flow capable models (devinavery, 23:16:14) * Flow capable based NSFs (devinavery, 23:16:29) * Abstract protocol Framework (devinavery, 23:16:56) * Config Subsystem (devinavery, 23:17:07) * Netconf Protocol (devinavery, 23:17:41) * 1) Netconf connector for MD-SAL and 2) for config subsystem (devinavery, 23:18:00) * Karaf Branding / Base Structure (devinavery, 23:18:42) * Some "Third-Party" Libraries (SSH Openflowj) (devinavery, 23:19:23) * Legacy Container (devinavery, 23:19:35) * Various ARchetypes (devinavery, 23:20:46) * Netty config binding - defines the config sub system hooks and used by a few various hooks (devinavery, 23:22:48) * openflow stats managers (AD-SAL & MD-SAL) (devinavery, 23:24:04) * Neutron system (devinavery, 23:24:41) * Datastore implementations (devinavery, 23:25:45) * So we have a lot of "stuff" here.. what should we do? (devinavery, 23:27:46) * There are multiple ways to achieve this - we can do build time control to choose what we want, or runtime control to only load what we want (devinavery, 23:28:10) * Do we want to create a "platform" and pull out the small pieces that make that possible? If so what are those small pieces (devinavery, 23:29:06) * Can we maybe create some projects out of all of these projects? (devinavery, 23:29:49) * there is a spectrum - Karaf is also a platform. What additional services are we adding on topic of karaf as a platform? Are they network services? (devinavery, 23:30:13) * defining the applications you are controlling can help lead to the decision of what we want in a controller or how to split it up (devinavery, 23:30:40) * Suggestion - lets pull out logical units instead of "kicking" something out (devinavery, 23:31:56) * suggestion, come up with some criteria to pull out the code (devinavery, 23:32:10) * Question: Are we planning to restructure the project structure at all? (devinavery, 23:33:07) * We have AD-SAL code, and MD-SAL Code - should we start by splitting here? (And then refactored the code) (devinavery, 23:34:11) * If we split AD-SAL and MD-SAL what are the applications that are used on each? (devinavery, 23:34:35) * What are the "core services"? Tony - one application or use case isn't enough to define a core service. We need many samples (devinavery, 23:35:09) * Suggestion - Pull out MD-SAL into its own project, with the config system? (devinavery, 23:36:05) * Question - why pull out MD-SAL and not AD-SAL? Answer - Because it is better defined? (devinavery, 23:36:23) * - Question what would you call the old AD-SAL? (devinavery, 23:36:35) * - Question - what are those services that we want to define a platform (devinavery, 23:37:11) * Suggestion - lets define our use-cases and have a data flow diagram that shows us what is going on and how to partition the code (devinavery, 23:38:03) * Tonight think about what you would like to break out of the controller project and what use-cases you have to break that out. And be prepared to share tomorrow. We will define a proposal to break out at least one thing from the controller project. (devinavery, 23:40:05) * We will meet again tomorrow during an unconference time. (devinavery, 23:40:58) Meeting ended at 23:41:01 UTC. People present (lines said) --------------------------- * devinavery (59) * odl_meetbot (3) Generated by `MeetBot`_ 0.1.4