Here is the Zoom info. Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/378977881
Or iPhone one-tap : US: +16699006833,,378977881# or +16465588656,,378977881# Or Telephone: Dial(for higher quality, dial a number based on your current location): US: +1 669 900 6833 or +1 646 558 8656 or +1 877 369 0926 (Toll Free) or +1 855 880 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