16:05:55 <colindixon> #startmeeting MD-SAL Ineterest Call
16:05:55 <odl_meetbot> Meeting started Tue Jul 14 16:05:55 2015 UTC.  The chair is colindixon. Information about MeetBot at http://ci.openstack.org/meetbot.html.
16:05:55 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:05:55 <odl_meetbot> The meeting name has been set to 'md_sal_ineterest_call'
16:05:59 <colindixon> #topic agenad
16:06:01 <colindixon> #undo
16:06:01 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Topic object at 0x193c910>
16:06:03 <colindixon> #topic agenda
16:06:09 <colindixon> #info spillover from clustering call
16:06:19 <colindixon> #into topics for the Be design forum
16:06:26 <colindixon> #info planned things for beryllium
16:07:16 <colindixon> #topic proposed Beryliium MD-SAL tree APIs and sharding APIs (spillover from clustering call)
16:07:26 <colindixon> #chair phrobb
16:07:26 <odl_meetbot> Current chairs: colindixon phrobb
16:09:41 <colindixon> #info if you’re interested, there is a recording for the clustering hackers call immediately before this one, which should give more context
16:10:13 <colindixon> #info some problems from Helium: data change listeres on multiple subtrees don’t provide any ordering guarantees
16:10:14 <phrobb> #link https://meetings.webex.com/collabs/url/S5R3Ri78y14q6I5wUliP1-2bEFqpAB1xhdb8KioOzYW00000  <-- The link to the recording from the Cluster Hacker's call
16:11:09 <colindixon> #info also, affected shards were only known during writes to the transactions, not ahead of time
16:11:20 <colindixon> #info also, no throttling or brachting of transactions
16:11:29 <colindixon> #info also something about reads being a problem, but I dind’t quite catch it
16:11:32 <colindixon> #topic proposed solutions
16:11:42 <colindixon> #info Datat treep API provides new features
16:11:59 <colindixon> #info subtree-bound transactions which can only read/write to a given subtree
16:12:17 <colindixon> #info all based on transaction chaining, better threading model, enforcement of a single writer
16:13:24 <colindixon> #Info tony goes into notable changes
16:14:01 <colindixon> #info 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
16:15:49 <colindixon> #info controversially, these new APIs do away with read() and instead means that people can only get data via data change notifications
16:16:16 <colindixon> #info moiz says that he things we’re going to need read(), tony says maybe, but it should be discouraged
16:16:30 <colindixon> #info tom pantelis says he thinks read() will still be common
16:16:47 <colindixon> #info there are three common patterns: producer, consumer, and transformer
16:23:10 <colindixon> #info 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
16:24:25 <colindixon> #info tony says, yeah that would require apps to be shard-aware, which we might or might not be able to assume that
16:24:58 <colindixon> #Info colindixon says that in practice, high-performance apps are very likely to be written to be shard aware anyway
16:28:21 <colindixon> #info 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
16:28:48 <colindixon> #info colindixon says that orthongonal to whether apps will choose to write cross-shard transactiions if they know
16:29:09 <colindixon> #info moiz says won’t this wind up with every node being a replica of ever shard, which will also hurt perfomance
16:42:39 <colindixon> #info tony points out that these APIs are designed to be low-level APIs, not designed for normal application writers
16:48:02 <colindixon> #info there is a lot of discussion around how these APIs will be suitable or not for certain circumstances, e.g., OpenFlow
16:48:30 <colindixon> #info 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
16:48:55 <colindixon> #info tony says that’s fine, but wants to make sure to focus on the broader ODL use cases
16:55:13 <colindixon> #action tony to post the HTML docs he was showing during the meeting and send it out
16:56:09 <colindixon> #topic beryllium dev forum topics
16:56:16 <colindixon> #link https://wiki.opendaylight.org/view/Events:Be_Dev_Forum
16:57:33 <colindixon> #link https://lists.opendaylight.org/pipermail/tsc/2015-July/003442.html moiz will post a lot of clustering topics (see this mail)
16:58:18 <colindixon> #info some of what was covered here is likely to be part of that
16:59:50 <colindixon> #topic during the next week
17:00:08 <colindixon> #info tony will post the preliminary release plans for yantools, controller, netconf and md-sal in the next week
17:01:42 <colindixon> #info it sounds like next week, there are still issues that TomP and Moiz would like to go through here
17:02:02 <colindixon> #info for example, Moiz thinks that we need to spend more time thinking about microsharding and how it interacts with data changes
17:03:46 <colindixon> #info TomP asks if we want to do this in a waterfall style or agile style, there are lots of things to deal with here
17:10:35 <colindixon> #endmeeting