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

Reply via email to