22:56:26 <devinavery> #startmeeting Breaking up the controller
22:56:26 <odl_meetbot> Meeting started Mon Sep 29 22:56:26 2014 UTC.  The chair is devinavery. Information about MeetBot at http://ci.openstack.org/meetbot.html.
22:56:26 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:56:26 <odl_meetbot> The meeting name has been set to 'breaking_up_the_controller'
22:57:04 <devinavery> #topic Whats Wrong with the controller?
22:57:06 <devinavery> #info takes a long time to build
22:57:50 <devinavery> #info - a deep tree makes it hard to find what you are looking for if you have a really deep nested tree
22:58:20 <devinavery> #info The names of the maven artifact don't match the folder structure
22:58:32 <devinavery> #info Takes a long time to start
22:59:13 <devinavery> #info different sub systems in one project allows for relaxed API control
23:00:43 <devinavery> #info 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
23:01:31 <devinavery> #info Unused code / dead code
23:02:36 <devinavery> #info Huge number of committers that can not always review all code - leads to confusion on the overall direction of the project
23:03:36 <devinavery> #topic - Question - What belongs in the "controller"?
23:04:04 <devinavery> #info Robert V suggest the "controller" is more of a platform for development
23:09:02 <devinavery> #info The controller should be a platform which provides "general" services (to be defined)
23:09:32 <devinavery> #info One suggestion is that the controller platform should not contain network services models
23:09:44 <devinavery> #info One thought - should have very few yang models in it
23:10:00 <devinavery> #info Question - why call it a controller if it is not controlling anything? Suggestion we could change the "name"of this project
23:10:24 <devinavery> #info If we call it a controller we should control something
23:11:40 <devinavery> #info Thought - controller means it controls something - traffic perhaps?
23:13:19 <devinavery> #info Platform to provide capabilities to manage the traffic, but not the applications
23:14:54 <devinavery> #topic What are the sub components?
23:15:02 <devinavery> #info AD-SAL Openflow Controller
23:15:14 <devinavery> #info AD-SAL clustering infrastructure
23:15:35 <devinavery> #info MD-SAL, RESTCONF, clustering
23:15:55 <devinavery> MD-SAL Extension services (xSql, Sample code)
23:16:04 <devinavery> #info MD-SAL Extension services (xSql, Sample code)
23:16:14 <devinavery> #info Flow capable models
23:16:29 <devinavery> #info Flow capable based NSFs
23:16:56 <devinavery> #info Abstract protocol Framework
23:17:07 <devinavery> #info Config Subsystem
23:17:41 <devinavery> #info Netconf Protocol
23:18:00 <devinavery> #info 1) Netconf connector for MD-SAL and 2) for config subsystem
23:18:42 <devinavery> #info Karaf Branding / Base Structure
23:19:23 <devinavery> #info Some "Third-Party" Libraries (SSH Openflowj)
23:19:35 <devinavery> #info Legacy Container
23:20:46 <devinavery> #info Various ARchetypes
23:22:48 <devinavery> #info Netty config binding - defines the config sub system hooks and used by a few various hooks
23:24:04 <devinavery> #info openflow stats managers (AD-SAL & MD-SAL)
23:24:41 <devinavery> #info Neutron system
23:25:45 <devinavery> #info Datastore implementations
23:27:46 <devinavery> #topic So we have a lot of "stuff" here.. what should we do?
23:28:10 <devinavery> #info  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
23:29:06 <devinavery> #info Do we want to create a "platform" and pull out the small pieces that make that possible? If so what are those small pieces
23:29:49 <devinavery> #info Can we maybe create some projects out of all of these projects?
23:30:13 <devinavery> #info 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?
23:30:40 <devinavery> #info 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
23:31:56 <devinavery> #info Suggestion - lets pull out logical units instead of "kicking" something out
23:32:10 <devinavery> #info suggestion, come up with some criteria to pull out the code
23:33:07 <devinavery> #info Question: Are we planning to restructure the project structure at all?
23:34:11 <devinavery> #info We have AD-SAL code, and MD-SAL Code - should we start by splitting here? (And then refactored the code)
23:34:35 <devinavery> #info If we split AD-SAL and MD-SAL what are the applications that are used on each?
23:35:09 <devinavery> #info What are the "core services"? Tony - one application or use case isn't enough to define a core service. We need many samples
23:36:05 <devinavery> #info Suggestion - Pull out MD-SAL into its own project, with the config system?
23:36:23 <devinavery> #info Question - why pull out MD-SAL and not AD-SAL? Answer - Because it is better defined?
23:36:35 <devinavery> #info - Question what would you call the old AD-SAL?
23:37:11 <devinavery> #info - Question - what are those services that we want to define a platform
23:38:03 <devinavery> #info 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
23:40:05 <devinavery> #info 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.
23:40:58 <devinavery> #info We will meet again tomorrow during an unconference time.
23:41:01 <devinavery> #endmeeting