Casey, is there a room for those at ons? On Wed, Mar 28, 2018, 9:31 AM 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 > _______________________________________________ > 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