14:02:56 #startmeeting datastore 14:02:56 Meeting started Mon May 12 14:02:56 2014 UTC. The chair is regXboi. Information about MeetBot at http://ci.openstack.org/meetbot.html. 14:02:56 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:02:56 The meeting name has been set to 'datastore' 14:03:01 #chair alagalah 14:03:01 Current chairs: alagalah regXboi 14:03:27 #link https://plus.google.com/hangouts/_/calendar/ZHZvcmtpbkBub2lyb25ldHdvcmtzLmNvbQ.e7ngfp46nqhv5oltibelval6o8?authuser=1 14:03:39 #info link is the google hangout 14:04:31 #topic general chit chat about our various weekend adventures 14:04:45 #info regXboi Didn't get shark-nado'd so we are happy 14:05:04 #topic Jan presenting on Datastore with Akka et al 14:05:18 #info discussion of datastore implementation based on APIC/Akka 14:05:32 regXboi: Keeping scribing to min. ie #info on context for #actions :) 14:05:41 regXboi: me that is... 14:06:03 #info distributed data store wiki link below 14:06:28 whoops 14:06:35 I was gunna say 14:06:39 Where'd ya goooooooo 14:06:44 #link https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Architecture:Clustered_Data_Store 14:06:57 I went to get the link and forgot which tab was front and center :) 14:07:48 #link https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Architecture:Clustered_Data_Store#Rough_requirements_for_Helium <- what it says it is 14:09:09 #info question on requirements #2 and #3 - is replication the responsibility of the data store or the persistence layer? 14:10:15 #info question from alagalah about if sharding is following the model where the service is co-located with its data 14:10:44 #info answer: that is the intent, but it is not clear if specifying co-location is possible via RESTCONF 14:11:15 #info alagalah satisfied, letting go of the bone 14:11:19 #info jmedved elaborated that the idea was to have a pluggable policy for apps to use the datastore 14:11:33 #info and for helium, the likely implementation will mimic APIC 14:12:47 #info regXboi asks re: requirements 2,3 from above link, who is responsible for replication. 14:13:22 #info moiz responds that it's the datastore's responsibility. Is going to share persistent object from primary to slaves via Akka. 14:14:14 #info regXboi asks if primary is only area of persistence (implying replicas are in memory) but moiz points out that replicas will be persistent too. 14:14:21 regXboi: Close? 14:14:22 alagalah: can't join the call, since it's over 9 people...could you record and post it 14:15:20 hemanthravi: Still working on YouTube recording (hangouts on air) as there's "issues"... please follow along on IRC as best you can. 14:15:32 hemanthravi: Currently discussing Replication diagram from above link 14:15:53 hemanthravi: Next time I'll do WebEx when we have folks presenting 14:15:58 alagalah: ok, could you post the link again 14:16:05 #info regXboi tabling replication concern for later in the discussion 14:16:13 https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Architecture:Clustered_Data_Store 14:16:20 #info https://plus.google.com/hangouts/_/calendar/ZHZvcmtpbkBub2lyb25ldHdvcmtzLmNvbQ.e7ngfp46nqhv5oltibelval6o8?authuser=1 14:16:31 sorry alagalah -- realized I forgot context :( 14:16:40 thanks 14:16:45 #link https://plus.google.com/hangouts/_/calendar/ZHZvcmtpbkBub2lyb25ldHdvcmtzLmNvbQ.e7ngfp46nqhv5oltibelval6o8?authuser=1 link to hangout 14:17:01 tbachman: He needed the clustering data store link 14:17:06 tbachman: hangout is full 14:17:08 ah 14:17:26 #link https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Architecture:Clustered_Data_Store link to data store on ODL wiki 14:19:52 #info question about requirement #4 - how does lack of distributed transactions bounce against the common tenant 14:20:23 #action mike to answer the above info question on transcation vs common tenant storage 14:22:29 #info some more discussion about distributed transactions and how to make them more easy to implement 14:24:22 #info regXboi claims that number 5 in the requirement list is a MUST not a should, as it is absolutely necessary for audit. 14:25:08 #info question for raghu67_ about data size 14:26:20 #link https://wiki.opendaylight.org/view/Group_Policy:Scaling 14:26:52 #info jmedved to know what of that link is applicable to helium and also which repositories each number applies to... 14:27:50 #action regXboi to take another pass through the above link and add the information jmedved is asking for 14:29:19 #info discussing design principles 14:29:31 #link https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Architecture:Clustered_Data_Store#General_Design_Principles 14:29:39 #action alagalah to work with GBP team to add tasks to plan to test how we can integrate with Clustered/Sharded Data yet still develop to existing InMemory data store in the interim (in case they are not drop/replace perfectly) 14:37:41 #info regXboi asks about the ability to reconfigure the sharding structure (ie via JSON call) whilst the controller is running or does it require taking the cluster down, config, bring up 14:38:24 #info jmedved et al reply that it is an outstanding question they have considered. alagalah suggests for Helium we require taking down the cluster so we don't have to deal with consistency during re-config and shoot for something more dynamic in Lithium 14:39:02 #info regXboi suggests that for Helium we build in the RESTCONF API that lets us reconfig dynamically but return "501" ie. its extensible but not implemented. 14:39:34 #info jmedved clarifies that it may not be "RESTCONF" but more and API but in generalisation yes, extensible but not implemented to Helium is agreed upon 14:40:03 #agreed Dynamic configuration of the sharding structure will be stubbed but not implemented for Helium. For Helium controller down will be required. 14:41:50 #info question on whether shard placement should be pluggable or not 14:42:17 #info regXboi answers that it should be pluggable, but doesn't have to be in Helium time frame 14:43:35 #info proposal that a tool be created to allow for shard placement 14:44:08 #info subtopic: why akka 14:44:19 #link https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Architecture:Clustered_Data_Store#Akka 14:44:36 (sorry for all the links folks, but I want this to be available for the future) 14:44:55 regXboi: the links are great :-) 14:45:29 #info discussion of remoting, clustering and persistence from Akka 14:48:25 #action regXboi to read wiki page and put questions to the mailing list 14:48:51 #action next datastore meeting to be webex and continue discussion 14:49:14 #info proposal to go on a faster cadence next week to unblock implementation 14:52:05 #info couple the faster cadence with email to see what progress we can make : further discussion to go off line 14:52:23 #info due to remaining time, jumping to PoC items 14:52:36 #link https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Architecture:Clustered_Data_Store#Proof_of_Concept 14:53:42 #info regXboi pleas to others to read and comment on mailing list... 14:56:24 #info regXboi suggests that we are able to dump the keys and build indexes around that, but to do "APIC" style query we would need to search via attribute. 14:56:44 #info context of above comment was on querying the DOM tree of the datastore 14:56:52 regXboi: Thanks, sorry... 14:57:16 #info the issue here is how to support searching by value attribute without changing the existing data related API 14:58:08 #info I think we should be able to layer the attribute value based query API on top of the current API 14:58:14 #info regXboi points out on "query like filters" that there is an intern project pointed at this that *may* be leveragable 15:00:15 #info alagalah asks if the SB plugins haven't already solved the serialization problem? 15:00:36 #info jmedved and moiz answer that this is a different problem 15:01:27 #info this is serialization of the Akka messages themselves for communication to remote Akka instances 15:03:25 #info regXboi asks for mail to the list clarifying the data validation concept 15:03:37 #endmeeting