What is preventing you from using MD-SAL?
- 1 Overview
- 2 Stability
- 3 Consistency
- 4 Developer Usability
- 4.1 Confusion with generated classes – duplicate names differingonly by package leads to confusion.
- 4.2 Difficulty in traversing the DOM (building instance identifiers). Everyone uses helper classes
- 4.3 Confusion on purpose of many MD-SAL classes
- 4.4 Too much Yang: While Yang is a good tool I think its dependencies should be contained as part of a component tool chain..
- 4.5 MD-SAL is a “Large” framework with a lot of dependencies.
- 4.6 Unit Test Mocks & Module Loading
- 5 Debugability
- 6 Missing Features
- 7 Performance
- 7.1 Hashtable DataStore Implementation appears to slow exponentially
- 7.2 Converting BindingAware commits into Binding Independent commits adds debugging complexity, as well as introducing overhead (~5-8%).
- 7.3 Process Size: Not sure if it is MD-SAL specifically causing this, but ODL is a large process which consumes a large number of resources.
- 8 Documentation
- 9 Fix Error Handling
The following is a compilation of items discussed on the e-mail thread in response to the question "What is preventing you from using MD-SAL?" If you have follow up comments, please edit this document and place your comments along with your name in square brackets: i.e.
[Devin] This is a comment
With the first release there were a number of bugs that existed in MD-SAL proper.
- Proposal: Implement more JUnit tests / do not allow code to be merged without unit testing
Holes in Implementation – incomplete implementations leads to confusion on expected behavior vs missing behavior
- Proposal: Identify and prioritize filling missing holes
Multiple ways to do a task – [Clarification Needed]
- Binding Aware vs Binding Indentpendent?
- Just class naming? Or don’t like the two code paths?
- Attributes vs RPC vs Notifications
- OSGi Services vs (MD-SAL ??) Config System
- Proposal: expose all MD-SAL services via OSGI services so we are not forced to use two different methods.
Confusion with generated classes – duplicate names differingonly by package leads to confusion.
- InstanceIdentifier – we have a BA and BI version..
- Proposal: Rename InstanceIdentifier to be BAInstanceIdentifier and BIInstanceIdentifier
- Node: we have xml, json, odl inventory… lots of nodes already exist – can we rename it.
- Proposal: Rename MD-SAL Node (I think we mean OpendaylightInventory-Node?) to be something other than “Node” which is a very common, and overloaded term.
- Proposal [General] – Can we somehow try and make class names unique, but meaningful, during code generation?
Difficulty in traversing the DOM (building instance identifiers). Everyone uses helper classes
- Proposal: Merge the simplified API of building the instance identifiers into the builder…???
Confusion on purpose of many MD-SAL classes
- Proposal: Add at a minimum one or two meaningful sentences to every class explaining its purpose.
- Proposal: Break apart nested classes etc until one or two sentences is enough!
Too much Yang: While Yang is a good tool I think its dependencies should be contained as part of a component tool chain..
- Proposal: I would prefer to see a generic approach to plugins (northbound, southbound or otherwise) and have yang be a way to translate to that specific format instead of seeing yang crawl in a core dependency for all the rest of the platform / system.
MD-SAL is a “Large” framework with a lot of dependencies.
- Proposal: Decompose MD-SAL into smaller pieces, preferably a layered architecture which allows consumers to enage with MD-SAL and different levels.
Unit Test Mocks & Module Loading
- Provide examples and describe how it’s done in the existing components; also, document how it plug into the module lifecycle (exists in emails, need better documentation). Initial proposal here: OpenDaylight_Controller:Config:UnitTesting
Runtime generated code makes debugging MD-SAL code fairly complicated and unpredictable.
- Proposal: Limit or remove the run-time code generation
- Proposal: (Already implemented) Generate the runtime generated code and save the source to a file so it can be examined manually.
“Controller is Ready” status.
- As a north bound application developer, I need to know when the controller is ready to accept all requests from NB / SB interfaces, so I can be sure requests from my system will be processed correctly (and not fail due to a resource that is missing).
- NOTE: This problem is solved for RESTConf by making it register for YANG convergence events and have it reload its cache based on these events. However, from the controller, it is impossible to say when the controller is really ready.
- Need to add the ‘Run’ phase to the lifecycle, and document the whole lifecycle (AI: Robert, ETA: ???)
- Create a configuration shim (a subsystem) that will allow to create module wiring configurations from Java annotations and make wiring configs much easier for Java developers. initial proposal by Raghu Bhat is here: OpenDaylight_Controller:Config:JavaShim' Robert or Tomas Olvecky has an AI to figure out how to map the shim onto the existing config subsystem and to investigate what simplifications are possible in the current config subsystem for Helium)
Clustering Services: Hydrogen release was missing MD-SAL clustering.
- Proposal: (Already is in progress with Akka experiements etc)Make this a priority to implement sooner rather than later.
Hashtable DataStore Implementation appears to slow exponentially
- Proposal: (Already in progress) Implement a TreeDataStore (some concerns remain)
Converting BindingAware commits into Binding Independent commits adds debugging complexity, as well as introducing overhead (~5-8%).
- Proposal: Consider different code paths for BA/ BI service to maintain performance?
Process Size: Not sure if it is MD-SAL specifically causing this, but ODL is a large process which consumes a large number of resources.
- Proposal: Split the controller up into multiple smaller processes.
- Toaster code should show proper error handling (Bug 1112)
- AI Tony sync up with Devin about proper Netconf error handling
- Document how to use the Data Store API properly (read/modify write w. error handling/retry cycle) Bug 1111
- Describe RPC Error handling Bug 1118
Fix Error Handling
- Promote DS Data pre-condition fail exceptions into the public DS API - Bug 1106;
* Fix RPC error handling - bugs 1117