We need to put together a better summary of what was discussed and AIs ☺ for 
those who were not there. Where should we capture, do we want to set up a jira 
or wiki page?
Abhijit had sent out a 2nd picture which captured some of the AIs. michael, can 
you please add that one as well to the album, I couldn’t edit it.

Thanks,
daya


From: Michael Vorburger [mailto:vorbur...@redhat.com]
Sent: Tuesday, April 03, 2018 8:15 PM
To: Muthukumaran K <muthukumara...@ericsson.com>
Cc: Casey Cain <cc...@linuxfoundation.org>; mdsal-...@lists.opendaylight.org; 
integration-...@lists.opendaylight.org <d...@lists.opendaylight.org>; Dayavanti 
Gopal Kamath <dayavanti.gopal.kam...@ericsson.com>; Stephen Kitt 
<sk...@redhat.com>; controller-dev <controller-dev@lists.opendaylight.org>
Subject: Re: [controller-dev] [opendaylight-dev] Topic : "Replacing the MD-SAL 
data store with etcd or something else"

On Thu, Mar 29, 2018 at 7:10 AM, Muthukumaran K 
<muthukumara...@ericsson.com<mailto:muthukumara...@ericsson.com>> wrote:
Is there any summary of points discussed during the meeting on this topic ?

https://photos.app.goo.gl/XeI4b2co7pisR4Xk2 ;-)

Regards
Muthu

From: 
controller-dev-boun...@lists.opendaylight.org<mailto:controller-dev-boun...@lists.opendaylight.org>
 
[mailto:controller-dev-boun...@lists.opendaylight.org<mailto:controller-dev-boun...@lists.opendaylight.org>]
 On Behalf Of Michael Vorburger
Sent: Wednesday, March 28, 2018 10:06 PM
To: Casey Cain
Cc: mdsal-...@lists.opendaylight.org<mailto:mdsal-...@lists.opendaylight.org>; 
integration-...@lists.opendaylight.org<mailto:integration-...@lists.opendaylight.org>;
 Dayavanti Gopal Kamath; Stephen Kitt; controller-dev
Subject: Re: [controller-dev] [opendaylight-dev] Topic : "Replacing the MD-SAL 
data store with etcd or something else"

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<mailto: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<tel:(669)%20900-6833>,,378977881# or 
+16465588656<tel:(646)%20558-8656>,,378977881#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 669 900 6833<tel:(669)%20900-6833> or +1 646 558 
8656<tel:(646)%20558-8656> or +1 877 369 0926<tel:(877)%20369-0926> (Toll Free) 
or +1 855 880 1246<tel:(855)%20880-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<mailto:afrede...@redhat.com>> wrote:
Is this confirmed?

Thanks,
Andre

On Tue, Mar 27, 2018 at 10:14 AM Abhijit Kumbhare 
<abhijitk...@gmail.com<mailto: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<mailto: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<mailto:n...@hq.sk>]
Sent: Tuesday, December 27, 2016 9:10 PM
To: Muthukumaran K 
<muthukumara...@ericsson.com<mailto:muthukumara...@ericsson.com>>; Colin Dixon 
<co...@colindixon.com<mailto:co...@colindixon.com>>; Shrenik Jain 
<shrenik.j...@research.iiit.ac.in<mailto:shrenik.j...@research.iiit.ac.in>>
Cc: 
integration-...@lists.opendaylight.org<mailto:integration-...@lists.opendaylight.org>
 <d...@lists.opendaylight.org<mailto:d...@lists.opendaylight.org>>; 
controller-dev 
<controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>>;
 mdsal-...@lists.opendaylight.org<mailto:mdsal-...@lists.opendaylight.org>; 
intern-ad...@opendaylight.org<mailto: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<mailto:controller-dev@lists.opendaylight.org>
https://lists.opendaylight.org/mailman/listinfo/controller-dev

_______________________________________________
dev mailing list
d...@lists.opendaylight.org<mailto: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