17:08:52 <colindixon> #startmeeting
17:08:52 <odl_meetbot> Meeting started Mon Mar 17 17:08:52 2014 UTC.  The chair is colindixon. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:08:52 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:09:05 <colindixon> #topic TWS call looking at MD-SAL with a focus on the new datastore
17:09:33 <alagalah> #info in
17:13:38 <colindixon> #topic issues we're looking to solve
17:14:35 <colindixon> #info we don't have a way to do atomic operations on subtrees, i.e., transactions
17:15:03 <colindixon> #info we don't have a way to do asynchronous reads/writes to the MD-SAL
17:16:02 <colindixon> #info at the same time, we'd like to improve read/write throughput
17:18:26 <colindixon> #info 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.
17:24:40 <GiovanniMeo> please look at jboss tree cache
17:24:41 <GiovanniMeo> http://docs.jboss.org/jbosscache/1.4.0/TreeCache/en/html_single/
17:28:29 <colindixon> #topic possible solutions
17:29:07 <colindixon> #link 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
17:29:58 <colindixon> #info 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
17:31:09 <cdub_> haha
17:31:12 <cdub_> more coherent
17:31:50 <dbainbri> (not on call, but lurking) wondering if we need to allow the caller to specify constraints around a call to know when a call should go over the wire or not. for a cluster on a LAN this may not be as much of an issue as when it may go over the WAN to another cluster.
17:33:10 <colindixon> #info 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
17:33:45 <cdub_> dbainbri: it's been touched on.  more from the point that those details (operation latency) is important and hidden when focused on a transparent api
17:34:22 <GiovanniMeo> #link http://infinispan.org/docs/6.0.x/user_guide/user_guide.html#_tree_api_module for infinispan tree api
17:34:32 <dbainbri> cdub_: thanks, always worries when systems think they are smart enough to hide from client when to go over the wire.
17:35:48 <colindixon> dbainbri: agree
17:35:56 <GiovanniMeo> brainbri: i totally agree in fact i believe when crossing a node
17:36:12 <GiovanniMeo> you should not really see that as painless RPC
17:36:27 <GiovanniMeo> because else you would fall in the error
17:36:33 <GiovanniMeo> that ok will cost nothing
17:37:10 <colindixon> #topic next steps
17:39:29 <colindixon> #info 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.
17:40:59 <colindixon> #info 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
17:42:07 <colindixon> #info 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
17:44:01 <colindixon> others should feel free to #info things here
17:44:10 <colindixon> I'm just trying to get the core things down
17:49:51 <alagalah> Well we need to
17:50:11 <cdub_> that won't work
17:50:18 <cdub_> services share underlying objects
17:50:42 <colindixon> cdub_: I know
17:52:40 <colindixon> #info 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?
17:53:11 <cdub_> garbage collection isn't free
17:53:34 <colindixon> #info 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
17:53:52 <colindixon> cdub_: that is very true and something we haven't paid enough attention to
17:56:45 <prasanna> should we continue this discussion sometime this week only
17:57:37 <dbainbri> does this mean that the static snapshots are outside the implementation (or implemented on top of) the underlying datastore? in other words, if someone implemented storage using MongoDB or Neo how would this interact with the snapshots?
17:57:46 <dbainbri> (yes, i should be on the call, but can't)
17:58:16 <colindixon> #topic the actual API
17:58:28 <colindixon> #link https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Architecture:DOM_DataStore this is the document which was being discussed
17:59:01 <cdub_> and another pun...somehting that should be hashed out
17:59:28 <colindixon> can somebody give me the link to what Jan is projecting right now
17:59:36 <cdub_> https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Architecture:DOM_DataStore
18:00:30 <colindixon> #link 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)
18:02:30 <colindixon> #info 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
18:02:35 <colindixon> #topic for next time
18:02:36 <cdub_> #info another call to be schedule w/thin the next week
18:02:52 <cdub_> #info a plea for a concrete usecase to validate model against _before_ that call
18:03:09 <colindixon> #info colin also asks for some update as to the plan and coding
18:03:16 <colindixon> end of meeting: going once
18:03:22 <colindixon> (thanks for the help cdub_)
18:03:38 <cdub_> you bet, sorry i didn't capture more
18:03:38 <colindixon> end of meeting: going twice
18:03:54 <colindixon> and done
18:03:57 <colindixon> #endmeeting