And do we have a physical room? On Wed, 28 Mar 2018 09:31:00 -0700 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,,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 > >> > > > >
pgpDxhxcSadIa.pgp
Description: OpenPGP digital signature
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
