We are in Echo Park On Wed, Mar 28, 2018 at 9:38 AM Abhijit Kumbhare <abhijitk...@gmail.com> wrote:
> Ok - let’s meet there then. That is next to the room where we had our > sessions (Echo Park), right? > > On Wed, Mar 28, 2018 at 9:35 AM Michael Vorburger <vorbur...@redhat.com> > wrote: > >> 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,,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
