On Thu, Mar 29, 2018 at 7:10 AM, Muthukumaran K <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] *On Behalf Of *Michael > Vorburger > *Sent:* Wednesday, March 28, 2018 10:06 PM > *To:* Casey Cain > *Cc:* mdsal-...@lists.opendaylight.org; integration-dev@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> 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 <(669)%20900-6833>,,378977881# or +16465588656 > <(646)%20558-8656>,,378977881# > > Or Telephone: > > Dial(for higher quality, dial a number based on your current location): > > US: +1 669 900 6833 <(669)%20900-6833> or +1 646 558 8656 > <(646)%20558-8656> or +1 877 369 0926 <(877)%20369-0926> (Toll Free) or +1 > 855 880 1246 <(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> > wrote: > > Is this confirmed? > > > > Thanks, > > Andre > > > > On Tue, Mar 27, 2018 at 10:14 AM Abhijit Kumbhare <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> 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] > Sent: Tuesday, December 27, 2016 9:10 PM > To: Muthukumaran K <muthukumara...@ericsson.com>; Colin Dixon < > co...@colindixon.com>; Shrenik Jain <shrenik.j...@research.iiit.ac.in> > Cc: integration-...@lists.opendaylight.org <d...@lists.opendaylight.org>; > controller-dev <controller-dev@lists.opendaylight.org>; > mdsal-...@lists.opendaylight.org; 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 > https://lists.opendaylight.org/mailman/listinfo/controller-dev > > > > _______________________________________________ > dev mailing list > 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
