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

Reply via email to