17:07:23 #startmeeting 17:07:23 Meeting started Mon Apr 14 17:07:23 2014 UTC. The chair is colindixon. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:07:23 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:07:58 #topic Reviewing the Cisco/Insieme APIC controller's clustering and state management 17:08:16 #info similar to MD-SAL in the datastore design 17:08:47 #info core idea was that you don't want require network admin to be a DB expert as well 17:09:12 #info General DB (or K-V) store isn't going to solve things 17:10:42 #info this is because, there aren't good DBs for storing, subscribing to, and manipulating trees 17:11:22 #topic it's all about the trees 17:12:26 #info claim: everything is pretty much a tree, this is different from tables or other organization, e.g., OVSDB, SQL, etc. 17:12:58 #info APIC uses a managed object tree 17:13:34 #info everything is a classed object, objects are hierarchically organized, objects can be subclassed 17:16:28 #info a given object has one and only one parent (except the root which has no parent) 17:17:00 #info queries 17:17:06 #topic queries 17:17:52 #info can query by type (class or superclass), properties, unique name, scoping by subtree, or a combination of all of them 17:19:13 #info this whole thing is a very nice fit for RESTful interfaces 17:20:22 #info comparisons to the MD-SAL model 17:20:34 #topic comparisons to the MD-SAL model 17:20:53 #info this is very similar to the MD-SAL, but there are some key differences 17:21:10 #info RESTCONF doesn't allow class-based queries, for instance 17:21:43 #info this doesn't necessarily work with YANG, this is a bit more general, e.g., cross-references are not allowed in YANG 17:24:44 #info some discussion seems to point to the fact that this cross-referencing should be possible in YANG as well, but might take a bit of work 17:27:06 #topic sharding 17:27:36 #info the total tree is shared into subtrees with the root of subtrees being called "context roots" 17:28:05 #info the shards are then mapped onto nodes using consistent hashing (as in DHTs) 17:29:35 #info sharding is static (defined in the model by explicitly naming the context root) 17:33:44 #info the sharding is currently always based on the hierarchy, not based on properties of nodes or anything else 17:35:20 #info this means that you want to make sure that your hierarchy is going to match your query patterns so that queries tend to stay in the same shard 17:35:50 #info mike dvorkin notes that this is a trade-off you *have* to make if you're going to shard. colindixon agrees. 17:37:40 #topic shard replication 17:38:02 #info shards are replicated 3 times: one is the "leader" and two are "followers" 17:41:01 #info Madhu asks how the different sections of this presentation are related, and how this is related to the MD-SAL 17:41:58 #info jan medved and mike dvorkin say basically, this is looking at how to model hierarchical data, and store it efficiently in a clustered sense, it's very similar to how the MD-SAL stores data 17:44:05 #info a longer discussion between jan, Madhu, and GiovanniMeo about how to build these things and how this works with Akka, vs. the MD-SAL in-memory data store vs. Infiinspan vs. APIC data store 17:46:40 #topic wider discussion of data stores 17:46:51 #info GiovanniMeo asks why not infinispan 17:47:13 #info colindixon says it's trees and consistency trade-offs seemingly being strange in Infinispan 17:48:28 #info jan medved says (and colindixon agrees) that we really need this for helium (at least with one good implementation) 17:48:52 #info jan would like to have many implementations which we could then test and evaluate 17:49:24 #info colindixon says that would be great, but at some point practicalities will likely insist that we don't have 4 different implementations 17:49:31 #topic back to sharding replication 17:54:09 #info leaders and followers are statically placed, if a leader fails, a follower steps up 17:55:35 #info the assumption, however, is that the leader being down is temporary and that when it comes up things will be moved back to it as soon as it catches up 17:57:17 #info no new followers or leaders are added in response to the failure as the assumption is that it will recover soon 17:58:05 #topic service/app model 18:02:16 #info the general effort is to co-located code (for services) with their data based on shards 18:02:27 #topic scheduling next meeting 18:03:34 #info we will continue this and the Akka discussion in meetings later this week with details to be sent to the mailing list 18:03:38 #endmeeting