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