I have not got the confirmation for the room or the Zoom - but Chris had said that he will try to get the room Los Feliz. I also have spoken with Casey to setup the Zoom session. So let’s just land in the Los Feliz at 10 am Pacific and the remote folks can join by Zoom once that is setup.
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 >> >
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev