14:02:29 #startmeeting GBP datastore 14:02:29 Meeting started Mon May 19 14:02:29 2014 UTC. The chair is alagalah. Information about MeetBot at http://ci.openstack.org/meetbot.html. 14:02:29 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:02:29 The meeting name has been set to 'gbp_datastore' 14:02:41 #chair regXboi tbachman raghu67 14:02:41 Current chairs: alagalah raghu67 regXboi tbachman 14:03:18 #topic agenda bashing 14:03:36 #info only agenda item I have is new DC numbers at link below 14:03:46 #link https://wiki.opendaylight.org/view/Group_Policy:Scaling 14:05:26 #link https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Architecture:Clustered_Data_Store 14:09:36 #info raghu67 asks about what we're calling resolvers in the use cases 14:10:45 #info regXboi says the renderer takes all the particulars of the model, and renders it into the particular configuration language needed by the resolver 14:10:55 #info the resolve operation should be a local operation in most cases. 14:11:36 #info the only time it isn't local is when the operation is completely out of scope, in which case it goes back to the renderer for resolution. If not resolvable by the renderer, this leads to an exception path 14:12:18 #info regXboi believes we need the inventory of resolvers for the exception path -- hopes it's part of ODL's inventory. 14:12:37 #info This leads to the question of how big the inventory in ODL can be/gets 14:22:15 #info Moiz continues data store presentation 14:22:39 #info regXboi wants to make sure that we have architectural white space for auditing 14:23:02 #info Moiz says we can either use logging or a separate monitoring application for this. 14:23:21 #info regXboi claims that logging is not auditing 14:24:09 raghu67: asks if this is real-time monitoring, or something that can be analyzed at another time 14:24:09 Going AFK for 5min, getting kid ready for school 14:24:52 #info in the case of audit, want to know who did it, what authority that had to do it, and arguments provided so that a reply can be performed. 14:28:12 #info jumping down to call diagrams 14:28:36 #link https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Architecture:Clustered_Data_Store#Creating_a_new_transaction 14:29:53 Don't want to interrupt but this looks synchronous for all shards 14:30:01 regXboi: Is that how you are reading this"? 14:30:12 I'm going to ask 14:31:45 #info raghu67 asks whether we need to support distributed transactions across shards. alagalah says he doesn't believe we do. 14:32:09 #info alagalah asks whether the operations are synchronous for all shards 14:32:51 #info Moiz says that it's asynchronous, with the "ask" getting a future which can be called later 14:35:13 #info readams notes that there currently aren't any semantics for things like rollbacks in the current data store APIs 14:41:05 #info readams noticed that the change notifications API might be a bit broken, when considering a multi-thread context. For example, are notifications guaranteed to be dispatched from a single thread? 14:41:43 #info raghu67 notes that some interfaces pass entire subtrees, which can be expensive. 14:41:59 #info current commits are from a single thread, which may create performance issues later on 14:42:32 #info point that failed transaction objects are expected to be thrown away and a new transaction object allocated 14:50:22 #info discussion of better documentation and examples (and fixed code) and possibly fix API... 14:51:24 * regXboi looks at really broken VM :( 14:58:29 I have to go, apologies, got to head into office, seems like Rob has this 15:02:48 #info no meeting next week due to the holidy 15:04:34 I think we can #endmeeting? 15:04:46 Yes. I think we can 15:04:53 #endmeeting