We need to put together a better summary of what was discussed and AIs ☺ for those who were not there. Where should we capture, do we want to set up a jira or wiki page? Abhijit had sent out a 2nd picture which captured some of the AIs. michael, can you please add that one as well to the album, I couldn’t edit it.
Thanks, daya From: Michael Vorburger [mailto:vorbur...@redhat.com] Sent: Tuesday, April 03, 2018 8:15 PM To: Muthukumaran K <muthukumara...@ericsson.com> Cc: Casey Cain <cc...@linuxfoundation.org>; mdsal-...@lists.opendaylight.org; integration-...@lists.opendaylight.org <d...@lists.opendaylight.org>; Dayavanti Gopal Kamath <dayavanti.gopal.kam...@ericsson.com>; Stephen Kitt <sk...@redhat.com>; controller-dev <controller-dev@lists.opendaylight.org> Subject: Re: [controller-dev] [opendaylight-dev] Topic : "Replacing the MD-SAL data store with etcd or something else" On Thu, Mar 29, 2018 at 7:10 AM, Muthukumaran K <muthukumara...@ericsson.com<mailto:muthukumara...@ericsson.com>> wrote: Is there any summary of points discussed during the meeting on this topic ? https://photos.app.goo.gl/XeI4b2co7pisR4Xk2 ;-) Regards Muthu From: controller-dev-boun...@lists.opendaylight.org<mailto:controller-dev-boun...@lists.opendaylight.org> [mailto:controller-dev-boun...@lists.opendaylight.org<mailto:controller-dev-boun...@lists.opendaylight.org>] On Behalf Of Michael Vorburger Sent: Wednesday, March 28, 2018 10:06 PM To: Casey Cain Cc: mdsal-...@lists.opendaylight.org<mailto:mdsal-...@lists.opendaylight.org>; integration-...@lists.opendaylight.org<mailto:integration-...@lists.opendaylight.org>; Dayavanti Gopal Kamath; Stephen Kitt; controller-dev Subject: Re: [controller-dev] [opendaylight-dev] Topic : "Replacing the MD-SAL data store with etcd or something else" I can come, but did not understand which room... Shall we just meet in that developer area room with the tables? On Wed, 28 Mar 2018, 09:31 Casey Cain, <cc...@linuxfoundation.org<mailto:cc...@linuxfoundation.org>> wrote: Here is the Zoom info. Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/378977881 Or iPhone one-tap : US: +16699006833<tel:(669)%20900-6833>,,378977881# or +16465588656<tel:(646)%20558-8656>,,378977881# Or Telephone: Dial(for higher quality, dial a number based on your current location): US: +1 669 900 6833<tel:(669)%20900-6833> or +1 646 558 8656<tel:(646)%20558-8656> or +1 877 369 0926<tel:(877)%20369-0926> (Toll Free) or +1 855 880 1246<tel:(855)%20880-1246> (Toll Free) Meeting ID: 378 977 881 International numbers available: https://zoom.us/zoomconference?m=3N5Hunw-pq1P_JpmUXATbXXWSnyHqsBy On Wed, Mar 28, 2018 at 9:28 AM, Andre Fredette <afrede...@redhat.com<mailto:afrede...@redhat.com>> wrote: Is this confirmed? Thanks, Andre On Tue, Mar 27, 2018 at 10:14 AM Abhijit Kumbhare <abhijitk...@gmail.com<mailto:abhijitk...@gmail.com>> wrote: Hi folks, Resurrecting an old thread that we have talked about for a while. I believe some folks were planning to discuss this at the DDF but for some reason there was no topic proposed on this. Chris, Robert and I were discussing having a meeting about this sometime tomorrow morning - say at 10 am. Chris will be able to arrange a room for us. We can ask Casey to have a Zoom session. It will be great if you guys can attend - at least Robert, Tom, Michael, Stephen, Muthu, etc. Thanks, Abhijit On Sun, Jan 1, 2017 at 11:22 PM, Muthukumaran K <muthukumara...@ericsson.com<mailto:muthukumara...@ericsson.com>> wrote: Thanks for the explanation Robert. When we refer access pattern and shard layout, I assume that it is in context of a given transaction owned by an application - please correct me if I am wrong. As a detour, the reference to transactions leads to a bunch of questions on how MD-SAL transactions - as we know in context of IMDS, could map on to external backend for a given shard (which CDT enables) For few transaction capabilities which are inherent in IMDS, there may not be equivalent concept/support in an external backend of choice. For example, concept like Transaction Chain. Other implementation-specific aspects of transaction could also vary drastically - for example, a) Snapshotting+MVCC as "I" of ACID is applicable for IMDS - but may not be true in case of Etcd / Cassandra - this mismatch may not have deeper ramifications to the end-user b) strong-consistency for writes may be a do-it-yourself if backend choice is Cassandra whereas its ingrained in IMDS Does this essentially mean that based on choice of backend, some concepts of transactions could be just no-op/ will be thrown with an unsupported exception (eg. transaction-chain) to manage the uniformity of broker contracts? Regards Muthu -----Original Message----- From: Robert Varga [mailto:n...@hq.sk<mailto:n...@hq.sk>] Sent: Tuesday, December 27, 2016 9:10 PM To: Muthukumaran K <muthukumara...@ericsson.com<mailto:muthukumara...@ericsson.com>>; Colin Dixon <co...@colindixon.com<mailto:co...@colindixon.com>>; Shrenik Jain <shrenik.j...@research.iiit.ac.in<mailto:shrenik.j...@research.iiit.ac.in>> Cc: integration-...@lists.opendaylight.org<mailto:integration-...@lists.opendaylight.org> <d...@lists.opendaylight.org<mailto:d...@lists.opendaylight.org>>; controller-dev <controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>>; mdsal-...@lists.opendaylight.org<mailto:mdsal-...@lists.opendaylight.org>; intern-ad...@opendaylight.org<mailto:intern-ad...@opendaylight.org> Subject: Re: [controller-dev] Interested in Contribution : "Replacing the MD-SAL data store with etcd" On 12/27/2016 11:38 AM, Muthukumaran K wrote: > Hi Robert, > > Looking at > https://github.com/opendaylight/mdsal/blob/master/dom/mdsal-dom-api/sr > c/main/java/org/opendaylight/mdsal/dom/api/DOMDataTreeShardingService. > java > > Few clarifications: > For same prefix duplicate producers are not allowed - this is > understandable. But there is a possibility that two distinct > producers/shards can have overlapping prefixes - if this is allowed, > would not there be a scenario wherein we could end up with a superset > shard and subset shard > > Eg. Let's assume there is a subtree whose prefix is /a/b/c/d mapped to shard > 1 and another /a/b/c/d/e/f mapped to another shard. > In other words, we can have recursive shards (hypothetical worst case could > be that these recursive shards could have their own backend instances). > Would this not lead to relatively complex read and write routing > implementations? Are such overlaps prevented by Sharding service contracts ? This is allowed and the two shards have a parent/child relationship, where the parent understands that it has a subordinate shard. There can (in theory) be infinite nesting, although I am not sure if the implementation handles more than one level. As for complexity of data access... it is *relatively* complex, but all it really boils down to is a recursive scatter/gather algorithm, where the superior shard delegates parts of the request to its subordinates and merges the responses -- which is pretty much bread-and-butter when dealing with tree-based structures. In any case, while possible, we envision that most applications will only talk to leaf shards, hence scatter/gather will not kick in. The cost of determining which shard is the apex for a producer is paid when the producer is instantiated, hence the steady-state cost should typically be zero. If the application access pattern and sharding layout do not align, you will get sucky performance, similar to what you get if you try to write to multiple module-based shards today. But that is a deployment-time engineering and application co-existence issue, which we cannot solve at the infrastructure layer. Regards, Robert _______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org> https://lists.opendaylight.org/mailman/listinfo/controller-dev _______________________________________________ dev mailing list d...@lists.opendaylight.org<mailto:d...@lists.opendaylight.org> https://lists.opendaylight.org/mailman/listinfo/dev -- Casey Cain Technical Program Manager Linux Foundation _________________ IRC - CaseyODL Skype - wrathwolfk WeChat - okaru6
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev