#opendaylight-meeting: MD-SAL Ineterest Call

Meeting summary

1. agenda (colindixon, 16:06:03)
   1. spillover from clustering call (colindixon, 16:06:09)
   2. planned things for beryllium (colindixon, 16:06:26)
   
   
2. proposed Beryliium MD-SAL tree APIs and sharding APIs (spillover from clustering call) (colindixon, 16:07:16)
   1. if you’re interested, there is a recording for the clustering hackers call immediately before this one, which should give more context (colindixon, 16:09:41)
   2. some problems from Helium: data change listeres on multiple subtrees don’t provide any ordering guarantees (colindixon, 16:10:13)
   3. https://meetings.webex.com/collabs/url/S5R3Ri78y14q6I5wUliP1-2bEFqpAB1xhdb8KioOzYW00000 <-- The link to the recording from the Cluster Hacker's call (phrobb, 16:10:14)
   4. also, affected shards were only known during writes to the transactions, not ahead of time (colindixon, 16:11:09)
   5. also, no throttling or brachting of transactions (colindixon, 16:11:20)
   6. also something about reads being a problem, but I dind’t quite catch it (colindixon, 16:11:29)
   
   
3. proposed solutions (colindixon, 16:11:32)
   1. Datat treep API provides new features (colindixon, 16:11:42)
   2. subtree-bound transactions which can only read/write to a given subtree (colindixon, 16:11:59)
   3. all based on transaction chaining, better threading model, enforcement of a single writer (colindixon, 16:12:17)
   4. tony goes into notable changes (colindixon, 16:13:24)
   5. a subset is: ordered data change events, no need to do reads on data change notifications since the data is injected as part of the eveent (colindixon, 16:14:01)
   6. controversially, these new APIs do away with read() and instead means that people can only get data via data change notifications (colindixon, 16:15:49)
   7. moiz says that he things we’re going to need read(), tony says maybe, but it should be discouraged (colindixon, 16:16:16)
   8. tom pantelis says he thinks read() will still be common (colindixon, 16:16:30)
   9. there are three common patterns: producer, consumer, and transformer (colindixon, 16:16:47)
   10. tom pantelis says it would be great if we could make it so that transactions only wrote to one shard, but he thinks problem not (colindixon, 16:23:10)
   11. tony says, yeah that would require apps to be shard-aware, which we might or might not be able to assume that (colindixon, 16:24:25)
   12. colindixon says that in practice, high-performance apps are very likely to be written to be shard aware anyway (colindixon, 16:24:58)
   13. tony says that this proposal based on knowing what trees each clustered MD-SAL instance is listening to and writing too (based on the subtree-bound listeners and writers), this could be used to optimize shard leader and replica placement (colindixon, 16:28:21)
   14. colindixon says that orthongonal to whether apps will choose to write cross-shard transactiions if they know (colindixon, 16:28:48)
   15. moiz says won’t this wind up with every node being a replica of ever shard, which will also hurt perfomance (colindixon, 16:29:09)
   16. tony points out that these APIs are designed to be low-level APIs, not designed for normal application writers (colindixon, 16:42:39)
   17. there is a lot of discussion around how these APIs will be suitable or not for certain circumstances, e.g., OpenFlow (colindixon, 16:48:02)
   18. moiz and tom pantelis would like to see this look at the OpenFlow use case for some idea of if we’re doing the right thing shere (colindixon, 16:48:30)
   19. tony says that’s fine, but wants to make sure to focus on the broader ODL use cases (colindixon, 16:48:55)
   20. ACTION: tony to post the HTML docs he was showing during the meeting and send it out (colindixon, 16:55:13)
   
   
4. beryllium dev forum topics (colindixon, 16:56:09)
   1. https://wiki.opendaylight.org/view/Events:Be_Dev_Forum (colindixon, 16:56:16)
   2. https://lists.opendaylight.org/pipermail/tsc/2015-July/003442.html moiz will post a lot of clustering topics (see this mail) (colindixon, 16:57:33)
   3. some of what was covered here is likely to be part of that (colindixon, 16:58:18)
   
   
5. during the next week (colindixon, 16:59:50)
   1. tony will post the preliminary release plans for yantools, controller, netconf and md-sal in the next week (colindixon, 17:00:08)
   2. it sounds like next week, there are still issues that TomP and Moiz would like to go through here (colindixon, 17:01:42)
   3. for example, Moiz thinks that we need to spend more time thinking about microsharding and how it interacts with data changes (colindixon, 17:02:02)
   4. TomP asks if we want to do this in a waterfall style or agile style, there are lots of things to deal with here (colindixon, 17:03:46)

Action items

1. tony to post the HTML docs he was showing during the meeting and send it out

People present (lines said)

1. colindixon (45)
2. odl_meetbot (5)
3. phrobb (1)