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

Reply via email to