#opendaylight-devforum5: Breaking up the controller

Meeting summary

1. Whats Wrong with the controller? (devinavery, 22:57:04)
   1. takes a long time to build (devinavery, 22:57:06)
   2. - 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)
   3. The names of the maven artifact don't match the folder structure (devinavery, 22:58:20)
   4. Takes a long time to start (devinavery, 22:58:32)
   5. different sub systems in one project allows for relaxed API control (devinavery, 22:59:13)
   6. 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)
   7. Unused code / dead code (devinavery, 23:01:31)
   8. 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)
   
   
2. - Question - What belongs in the "controller"? (devinavery, 23:03:36)
   1. Robert V suggest the "controller" is more of a platform for development (devinavery, 23:04:04)
   2. The controller should be a platform which provides "general" services (to be defined) (devinavery, 23:09:02)
   3. One suggestion is that the controller platform should not contain network services models (devinavery, 23:09:32)
   4. One thought - should have very few yang models in it (devinavery, 23:09:44)
   5. 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)
   6. If we call it a controller we should control something (devinavery, 23:10:24)
   7. Thought - controller means it controls something - traffic perhaps? (devinavery, 23:11:40)
   8. Platform to provide capabilities to manage the traffic, but not the applications (devinavery, 23:13:19)
   
   
3. What are the sub components? (devinavery, 23:14:54)
   1. AD-SAL Openflow Controller (devinavery, 23:15:02)
   2. AD-SAL clustering infrastructure (devinavery, 23:15:14)
   3. MD-SAL, RESTCONF, clustering (devinavery, 23:15:35)
   4. MD-SAL Extension services (xSql, Sample code) (devinavery, 23:16:04)
   5. Flow capable models (devinavery, 23:16:14)
   6. Flow capable based NSFs (devinavery, 23:16:29)
   7. Abstract protocol Framework (devinavery, 23:16:56)
   8. Config Subsystem (devinavery, 23:17:07)
   9. Netconf Protocol (devinavery, 23:17:41)
   10. 1) Netconf connector for MD-SAL and 2) for config subsystem (devinavery, 23:18:00)
   11. Karaf Branding / Base Structure (devinavery, 23:18:42)
   12. Some "Third-Party" Libraries (SSH Openflowj) (devinavery, 23:19:23)
   13. Legacy Container (devinavery, 23:19:35)
   14. Various ARchetypes (devinavery, 23:20:46)
   15. Netty config binding - defines the config sub system hooks and used by a few various hooks (devinavery, 23:22:48)
   16. openflow stats managers (AD-SAL & MD-SAL) (devinavery, 23:24:04)
   17. Neutron system (devinavery, 23:24:41)
   18. Datastore implementations (devinavery, 23:25:45)
   
   
4. So we have a lot of "stuff" here.. what should we do? (devinavery, 23:27:46)
   1. 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)
   2. 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)
   3. Can we maybe create some projects out of all of these projects? (devinavery, 23:29:49)
   4. 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)
   5. 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)
   6. Suggestion - lets pull out logical units instead of "kicking" something out (devinavery, 23:31:56)
   7. suggestion, come up with some criteria to pull out the code (devinavery, 23:32:10)
   8. Question: Are we planning to restructure the project structure at all? (devinavery, 23:33:07)
   9. We have AD-SAL code, and MD-SAL Code - should we start by splitting here? (And then refactored the code) (devinavery, 23:34:11)
   10. If we split AD-SAL and MD-SAL what are the applications that are used on each? (devinavery, 23:34:35)
   11. 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)
   12. Suggestion - Pull out MD-SAL into its own project, with the config system? (devinavery, 23:36:05)
   13. Question - why pull out MD-SAL and not AD-SAL? Answer - Because it is better defined? (devinavery, 23:36:23)
   14. - Question what would you call the old AD-SAL? (devinavery, 23:36:35)
   15. - Question - what are those services that we want to define a platform (devinavery, 23:37:11)
   16. 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)
   17. 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)
   18. We will meet again tomorrow during an unconference time. (devinavery, 23:40:58)

Action items

1. (none)

People present (lines said)

1. devinavery (59)
2. odl_meetbot (3)