#opendaylight-meeting Meeting

Meeting summary

1. TWS call looking at MD-SAL with a focus on the new datastore (colindixon, 17:09:05)
   1. in (alagalah, 17:09:33)
   
   
2. issues we're looking to solve (colindixon, 17:13:38)
   1. we don't have a way to do atomic operations on subtrees, i.e., transactions (colindixon, 17:14:35)
   2. we don't have a way to do asynchronous reads/writes to the MD-SAL (colindixon, 17:15:03)
   3. at the same time, we'd like to improve read/write throughput (colindixon, 17:16:02)
   4. Jan states at the current point in time, there is no consideration for clustering, it is node-local, in-memory. Jan points out that in the future, we could add clustering behavior in a variety of ways. (colindixon, 17:18:26)
   5. http://docs.jboss.org/jbosscache/1.4.0/TreeCache/en/html_single/ (GiovanniMeo, 17:24:41)
   
   
3. possible solutions (colindixon, 17:28:29)
   1. http://docs.jboss.org/jbosscache/1.4.0/TreeCache/en/html_single/ GiovanniMeo points out that there is a TreeCache in the JBOSS framework which is related to the Infinispan that we use (colindixon, 17:29:07)
   2. there is discussion about how much we need to worry about clustering in the API now, colindixon points out that some APIs are easy to make cluster related, others are not so much and that transactions on trees one that is pretty hard (colindixon, 17:29:58)
   3. colindixon points out that if you want to have distributed transactions where data items are structurally inter-related, i.e., trees, the typical solution to avoid miserable performance is to partition the structure in a way that there are enough independent partitions to avoid contention, but then disallow cross-partition transactions (colindixon, 17:33:10)
   4. http://infinispan.org/docs/6.0.x/user_guide/user_guide.html#_tree_api_module for infinispan tree api (GiovanniMeo, 17:34:22)
   
   
4. next steps (colindixon, 17:37:10)
   1. it seems as though there are two issues: first, fixing the core performance of the MD-SAL data store for a stability release. second, figuring out the data store in the clustered and/or distributed environment in the longer term. (colindixon, 17:39:29)
   2. in the short-run, we need to fix the performance and the current plan of record to attack that is allowing for asynchronous reads and writes (colindixon, 17:40:59)
   3. a thread running through the whole call is to what degree it is possible (or even desirable) to hide when operations span multiple controller instances (colindixon, 17:42:07)
   4. colindixon asks about why the atomic subtree operations is listed here? is it a performance issue? or just a feature we'd like to have? (colindixon, 17:52:40)
   5. the answer appears to be that there is a belief that by doing static snapshots, we will allow for many reads simultaneously which should improve performance (colindixon, 17:53:34)
   
   
5. the actual API (colindixon, 17:58:16)
   1. https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Architecture:DOM_DataStore this is the document which was being discussed (colindixon, 17:58:28)
   2. https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Architecture:DOM_DataStore (cdub_, 17:59:36)
   3. https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Architecture:DOM_DataStore:Transactions this page includes links to the effective API that's being proposed (in gerrit) (colindixon, 18:00:30)
   4. colindixon notes that the scope, i.e., subtree in which the transaction operates, is implicit in the api while the transaction type, i.e., read, write or read/write, is explicit and is curious why (colindixon, 18:02:30)
   
   
6. for next time (colindixon, 18:02:35)
   1. another call to be schedule w/thin the next week (cdub_, 18:02:36)
   2. a plea for a concrete usecase to validate model against _before_ that call (cdub_, 18:02:52)
   3. colin also asks for some update as to the plan and coding (colindixon, 18:03:09)

Action items

1. (none)

People present (lines said)

1. colindixon (34)
2. cdub_ (11)
3. GiovanniMeo (7)
4. dbainbri (4)
5. alagalah (2)
6. odl_meetbot (2)
7. prasanna (1)