Re: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: OutOfMemory from datastore

2017-01-11 Thread Tom Pantelis 
It's not the while data store - snapshots occur per shard. But since
everything probably goes into one shard, it essentially is the whole DS.

No behavior change - this limit hadn't been hit until now.

On Wed, Jan 11, 2017 at 8:34 AM, Kochba, Alon  wrote:

> + Daniel and Marcus
>
>
>
> Jumping in here with some questions..
>
> Is the bottom line here that the *whole config DS* size cannot exceed 2GB
> or did I get something wrong?
>
> Is it possible we never encountered such a scenario in the S3P performance
> tests done in Beryllium/Boron [1], or did something change in the behavior?
>
>
>
> It seems that this limitation is extremely problematic for scale, and
> should be easily recreated by doing NetVirt scale tests (loading ~200
> computes and creating a VM on each, or configuring a TZ for all of them
> manually).
>
>
>
> I see 1800 OVSDB nodes were installed in [1], but not sure if any flows
> were configured on the OpenFlow side which might cause the DS to scale..
>
> We also need to monitor what part of the DS is taking so much space - we
> might have redundant data being stored catching up space, but in any case
> projects would hit 2GB at some point.
>
>
>
> [1] https://www.opendaylight.org/sites/www.opendaylight.org/files/odl_
> performancetechnicalreport_1-1_052716.pdf
>
> --alon
>
>
>
> *From:* netvirt-dev-boun...@lists.opendaylight.org [mailto:
> netvirt-dev-boun...@lists.opendaylight.org] *On Behalf Of *Sela, Guy
> *Sent:* Wednesday, 11 January 2017 11:23
> *To:* Tom Pantelis 
> *Cc:* odl netvirt dev ;
> controller-dev@lists.opendaylight.org; Robert Varga 
> *Subject:* Re: [netvirt-dev] [controller-dev] [mdsal-dev] Netvirt Scale
> tests: OutOfMemory from datastore
>
>
>
> Opened a bug:
>
> https://bugs.opendaylight.org/show_bug.cgi?id=7521
>
>
>
>
>
> *From:* Tom Pantelis [mailto:tompante...@gmail.com ]
>
> *Sent:* Wednesday, January 11, 2017 1:06 AM
> *To:* Sela, Guy 
> *Cc:* Robert Varga ; controller-dev@lists.opendaylight.org;
> odl netvirt dev 
> *Subject:* Re: [controller-dev] [mdsal-dev] Netvirt Scale tests:
> OutOfMemory from datastore
>
>
>
> operational won't snapshot if not persisted or replicated.
>
>
>
> Can you open a bug for tracking?
>
>
>
> On Tue, Jan 10, 2017 at 4:12 PM, Sela, Guy  wrote:
>
> Do the snapshot happen only to the configuration data store or to the
> operational as well?
>
> -Original Message-
> From: Robert Varga [mailto:n...@hq.sk]
> Sent: Tuesday, January 10, 2017 10:21 PM
> To: Tom Pantelis ; Sela, Guy 
>
> Cc: controller-dev@lists.opendaylight.org; odl netvirt dev <
> netvirt-...@lists.opendaylight.org>
> Subject: Re: [controller-dev] [mdsal-dev] Netvirt Scale tests: OutOfMemory
> from datastore
>
> On 01/10/2017 08:16 PM, Tom Pantelis wrote:
> > Since the length field of an array is an int, it's constrained to
> > Integer.MAX_VALUE (~2G). To handle snapshots larger than 2G we'll have
> > to chuck it into multiple byte[].
>
> That could get funky on the reassembly side of things. If we go that
> route, we may as well switch to something more friendly, like
> java.nio.ByteBuffer(), too.
>
> Guy, just out of curiosity: how much duplication is in your data set?
>
> Regards,
> Robert
>
>
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: OutOfMemory from datastore

2017-01-11 Thread Sela, Guy 
I have some blurriness about what a shard is, that I still didn’t figure out.
I have some guesses:

1)  Every yang tree == one shard.

2)  Shard can be a collection of a number of yang trees.

3)  None of the above?


From: Tom Pantelis [mailto:tompante...@gmail.com]
Sent: Wednesday, January 11, 2017 3:46 PM
To: Kochba, Alon 
Cc: Sela, Guy ; Williams, Marcus ; 
Daniel Farrell ; odl netvirt dev 
; controller-dev@lists.opendaylight.org; 
Robert Varga ; integration-...@lists.opendaylight.org
Subject: Re: [netvirt-dev] [controller-dev] [mdsal-dev] Netvirt Scale tests: 
OutOfMemory from datastore

It's not the while data store - snapshots occur per shard. But since everything 
probably goes into one shard, it essentially is the whole DS.

No behavior change - this limit hadn't been hit until now.

On Wed, Jan 11, 2017 at 8:34 AM, Kochba, Alon 
mailto:alo...@hpe.com>> wrote:
+ Daniel and Marcus

Jumping in here with some questions..
Is the bottom line here that the whole config DS size cannot exceed 2GB or did 
I get something wrong?
Is it possible we never encountered such a scenario in the S3P performance 
tests done in Beryllium/Boron [1], or did something change in the behavior?

It seems that this limitation is extremely problematic for scale, and should be 
easily recreated by doing NetVirt scale tests (loading ~200 computes and 
creating a VM on each, or configuring a TZ for all of them manually).

I see 1800 OVSDB nodes were installed in [1], but not sure if any flows were 
configured on the OpenFlow side which might cause the DS to scale..
We also need to monitor what part of the DS is taking so much space - we might 
have redundant data being stored catching up space, but in any case projects 
would hit 2GB at some point.

[1] 
https://www.opendaylight.org/sites/www.opendaylight.org/files/odl_performancetechnicalreport_1-1_052716.pdf
--alon

From: 
netvirt-dev-boun...@lists.opendaylight.org
 
[mailto:netvirt-dev-boun...@lists.opendaylight.org]
 On Behalf Of Sela, Guy
Sent: Wednesday, 11 January 2017 11:23
To: Tom Pantelis mailto:tompante...@gmail.com>>
Cc: odl netvirt dev 
mailto:netvirt-...@lists.opendaylight.org>>;
 
controller-dev@lists.opendaylight.org;
 Robert Varga mailto:n...@hq.sk>>
Subject: Re: [netvirt-dev] [controller-dev] [mdsal-dev] Netvirt Scale tests: 
OutOfMemory from datastore

Opened a bug:
https://bugs.opendaylight.org/show_bug.cgi?id=7521


From: Tom Pantelis [mailto:tompante...@gmail.com]
Sent: Wednesday, January 11, 2017 1:06 AM
To: Sela, Guy mailto:guy.s...@hpe.com>>
Cc: Robert Varga mailto:n...@hq.sk>>; 
controller-dev@lists.opendaylight.org;
 odl netvirt dev 
mailto:netvirt-...@lists.opendaylight.org>>
Subject: Re: [controller-dev] [mdsal-dev] Netvirt Scale tests: OutOfMemory from 
datastore

operational won't snapshot if not persisted or replicated.

Can you open a bug for tracking?

On Tue, Jan 10, 2017 at 4:12 PM, Sela, Guy 
mailto:guy.s...@hpe.com>> wrote:
Do the snapshot happen only to the configuration data store or to the 
operational as well?

-Original Message-
From: Robert Varga [mailto:n...@hq.sk]
Sent: Tuesday, January 10, 2017 10:21 PM
To: Tom Pantelis mailto:tompante...@gmail.com>>; Sela, 
Guy mailto:guy.s...@hpe.com>>
Cc: 
controller-dev@lists.opendaylight.org;
 odl netvirt dev 
mailto:netvirt-...@lists.opendaylight.org>>
Subject: Re: [controller-dev] [mdsal-dev] Netvirt Scale tests: OutOfMemory from 
datastore

On 01/10/2017 08:16 PM, Tom Pantelis wrote:
> Since the length field of an array is an int, it's constrained to
> Integer.MAX_VALUE (~2G). To handle snapshots larger than 2G we'll have
> to chuck it into multiple byte[].

That could get funky on the reassembly side of things. If we go that route, we 
may as well switch to something more friendly, like java.nio.ByteBuffer(), too.

Guy, just out of curiosity: how much duplication is in your data set?

Regards,
Robert


___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: OutOfMemory from datastore

2017-01-11 Thread Sela, Guy 
So what you mean is that if I create a yang tree in a yang file, it will 
ultimately translate into maximum two shards? 
One for the operational and one for the configuration?

So for example elan.yang:
container elan-interface-forwarding-entries {
config false;

list elan-interface-mac {
key "elan-interface";
description "All the MAC addresses learned on a particular elan 
interface";
max-elements "unbounded";
min-elements "0";
leaf elan-interface {
type leafref {
path "/if:interfaces/if:interface/if:name";
}
}

uses forwarding-entries;
}
} 

container elan-tag-name-map {
config false;

list elan-tag-name {
key elan-tag;
leaf elan-tag {
type uint32;
}

leaf name {
type string;
description
"The name of the elan-instance.";
}
}
}

These 2 only live in the operational (Because config false), so it means 2 
Shards ? 

-Original Message-
From: Robert Varga [mailto:n...@hq.sk] 
Sent: Wednesday, January 11, 2017 4:45 PM
To: Sela, Guy ; Tom Pantelis ; Kochba, 
Alon 
Cc: Williams, Marcus ; Daniel Farrell 
; odl netvirt dev ; 
controller-dev@lists.opendaylight.org; integration-...@lists.opendaylight.org
Subject: Re: [netvirt-dev] [controller-dev] [mdsal-dev] Netvirt Scale tests: 
OutOfMemory from datastore

On 01/11/2017 03:42 PM, Sela, Guy wrote:
> I have some blurriness about what a shard is, that I still didn’t 
> figure out.
> 
> I have some guesses:
> 
> 1)  Every yang tree == one shard.
> 
> 2)  Shard can be a collection of a number of yang trees.
> 
> 3)  None of the above?
> 

Mostly 1. Each shard encapsulates a single ShardDataTree, which encapsulates a 
single DataTree. The sum of shards is presented as the data store (CDS).

Regards,
Robert

___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: OutOfMemory from datastore

2017-01-11 Thread Robert Varga 
On 01/11/2017 03:42 PM, Sela, Guy wrote:
> I have some blurriness about what a shard is, that I still didn’t figure
> out.
> 
> I have some guesses:
> 
> 1)  Every yang tree == one shard.
> 
> 2)  Shard can be a collection of a number of yang trees.
> 
> 3)  None of the above?
> 

Mostly 1. Each shard encapsulates a single ShardDataTree, which
encapsulates a single DataTree. The sum of shards is presented as the
data store (CDS).

Regards,
Robert



signature.asc
Description: OpenPGP digital signature
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: OutOfMemory from datastore

2017-01-11 Thread Tom Pantelis 
Shards are (currently) statically configured in module-shards.conf. There's
3 OOB - "topology", "inventory", and "default". Anything not under topology
and inventory go into the default shard.

On Wed, Jan 11, 2017 at 9:51 AM, Sela, Guy  wrote:

> So what you mean is that if I create a yang tree in a yang file, it will
> ultimately translate into maximum two shards?
> One for the operational and one for the configuration?
>
> So for example elan.yang:
> container elan-interface-forwarding-entries {
> config false;
>
> list elan-interface-mac {
> key "elan-interface";
> description "All the MAC addresses learned on a particular
> elan interface";
> max-elements "unbounded";
> min-elements "0";
> leaf elan-interface {
> type leafref {
> path "/if:interfaces/if:interface/if:name";
> }
> }
>
> uses forwarding-entries;
> }
> }
>
> container elan-tag-name-map {
> config false;
>
> list elan-tag-name {
> key elan-tag;
> leaf elan-tag {
> type uint32;
> }
>
> leaf name {
> type string;
> description
> "The name of the elan-instance.";
> }
> }
> }
>
> These 2 only live in the operational (Because config false), so it means 2
> Shards ?
>
> -Original Message-
> From: Robert Varga [mailto:n...@hq.sk]
> Sent: Wednesday, January 11, 2017 4:45 PM
> To: Sela, Guy ; Tom Pantelis ;
> Kochba, Alon 
> Cc: Williams, Marcus ; Daniel Farrell <
> dfarr...@redhat.com>; odl netvirt dev ;
> controller-dev@lists.opendaylight.org; integration-dev@lists.
> opendaylight.org
> Subject: Re: [netvirt-dev] [controller-dev] [mdsal-dev] Netvirt Scale
> tests: OutOfMemory from datastore
>
> On 01/11/2017 03:42 PM, Sela, Guy wrote:
> > I have some blurriness about what a shard is, that I still didn’t
> > figure out.
> >
> > I have some guesses:
> >
> > 1)  Every yang tree == one shard.
> >
> > 2)  Shard can be a collection of a number of yang trees.
> >
> > 3)  None of the above?
> >
>
> Mostly 1. Each shard encapsulates a single ShardDataTree, which
> encapsulates a single DataTree. The sum of shards is presented as the data
> store (CDS).
>
> Regards,
> Robert
>
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: OutOfMemory from datastore

2017-01-11 Thread Sela, Guy 
Oh so that’s really different than option 1 I wrote.
You are saying that I have a capability of creating shards by taking different 
yang trees and combining them into shards?.
My smallest unit of work is a yang tree ?

I still don’t see how it is done.
Let’s say I wanted to take the 2 trees in my example and put them in one shard 
only for them.
How will module-shards.conf look like and how will modules.conf will look like?
If you have an example of that in some WIKI, you can just point me to that.


From: Tom Pantelis [mailto:tompante...@gmail.com]
Sent: Wednesday, January 11, 2017 4:58 PM
To: Sela, Guy 
Cc: Robert Varga ; Kochba, Alon ; Williams, Marcus 
; Daniel Farrell ; odl netvirt 
dev ; 
controller-dev@lists.opendaylight.org; integration-...@lists.opendaylight.org
Subject: Re: [netvirt-dev] [controller-dev] [mdsal-dev] Netvirt Scale tests: 
OutOfMemory from datastore

Shards are (currently) statically configured in module-shards.conf. There's 3 
OOB - "topology", "inventory", and "default". Anything not under topology and 
inventory go into the default shard.

On Wed, Jan 11, 2017 at 9:51 AM, Sela, Guy 
mailto:guy.s...@hpe.com>> wrote:
So what you mean is that if I create a yang tree in a yang file, it will 
ultimately translate into maximum two shards?
One for the operational and one for the configuration?

So for example elan.yang:
container elan-interface-forwarding-entries {
config false;

list elan-interface-mac {
key "elan-interface";
description "All the MAC addresses learned on a particular elan 
interface";
max-elements "unbounded";
min-elements "0";
leaf elan-interface {
type leafref {
path "/if:interfaces/if:interface/if:name";
}
}

uses forwarding-entries;
}
}

container elan-tag-name-map {
config false;

list elan-tag-name {
key elan-tag;
leaf elan-tag {
type uint32;
}

leaf name {
type string;
description
"The name of the elan-instance.";
}
}
}

These 2 only live in the operational (Because config false), so it means 2 
Shards ?

-Original Message-
From: Robert Varga [mailto:n...@hq.sk]
Sent: Wednesday, January 11, 2017 4:45 PM
To: Sela, Guy mailto:guy.s...@hpe.com>>; Tom Pantelis 
mailto:tompante...@gmail.com>>; Kochba, Alon 
mailto:alo...@hpe.com>>
Cc: Williams, Marcus 
mailto:marcus.willi...@intel.com>>; Daniel Farrell 
mailto:dfarr...@redhat.com>>; odl netvirt dev 
mailto:netvirt-...@lists.opendaylight.org>>;
 
controller-dev@lists.opendaylight.org;
 
integration-...@lists.opendaylight.org
Subject: Re: [netvirt-dev] [controller-dev] [mdsal-dev] Netvirt Scale tests: 
OutOfMemory from datastore
On 01/11/2017 03:42 PM, Sela, Guy wrote:
> I have some blurriness about what a shard is, that I still didn’t
> figure out.
>
> I have some guesses:
>
> 1)  Every yang tree == one shard.
>
> 2)  Shard can be a collection of a number of yang trees.
>
> 3)  None of the above?
>

Mostly 1. Each shard encapsulates a single ShardDataTree, which encapsulates a 
single DataTree. The sum of shards is presented as the data store (CDS).

Regards,
Robert

___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: OutOfMemory from datastore

2017-01-11 Thread Sela, Guy 
If my last mail is correct, it sounds a bit bug prone.
You are not allowed to create a single write transaction that writes to 
multiple shards.
How can you know in the code if you are writing to different shards or not ?
If you want to be on the safe side, you should avoid writing to different trees 
in a single transaction, because different trees could potentially be split to 
different shards.
Am I understanding correctly?

From: Sela, Guy
Sent: Wednesday, January 11, 2017 5:07 PM
To: 'Tom Pantelis' 
Cc: Robert Varga ; Kochba, Alon ; Williams, Marcus 
; Daniel Farrell ; odl netvirt 
dev ; 
controller-dev@lists.opendaylight.org; integration-...@lists.opendaylight.org
Subject: RE: [netvirt-dev] [controller-dev] [mdsal-dev] Netvirt Scale tests: 
OutOfMemory from datastore

Oh so that’s really different than option 1 I wrote.
You are saying that I have a capability of creating shards by taking different 
yang trees and combining them into shards?.
My smallest unit of work is a yang tree ?

I still don’t see how it is done.
Let’s say I wanted to take the 2 trees in my example and put them in one shard 
only for them.
How will module-shards.conf look like and how will modules.conf will look like?
If you have an example of that in some WIKI, you can just point me to that.


From: Tom Pantelis [mailto:tompante...@gmail.com]
Sent: Wednesday, January 11, 2017 4:58 PM
To: Sela, Guy mailto:guy.s...@hpe.com>>
Cc: Robert Varga mailto:n...@hq.sk>>; Kochba, Alon 
mailto:alo...@hpe.com>>; Williams, Marcus 
mailto:marcus.willi...@intel.com>>; Daniel Farrell 
mailto:dfarr...@redhat.com>>; odl netvirt dev 
mailto:netvirt-...@lists.opendaylight.org>>;
 
controller-dev@lists.opendaylight.org;
 
integration-...@lists.opendaylight.org
Subject: Re: [netvirt-dev] [controller-dev] [mdsal-dev] Netvirt Scale tests: 
OutOfMemory from datastore

Shards are (currently) statically configured in module-shards.conf. There's 3 
OOB - "topology", "inventory", and "default". Anything not under topology and 
inventory go into the default shard.

On Wed, Jan 11, 2017 at 9:51 AM, Sela, Guy 
mailto:guy.s...@hpe.com>> wrote:
So what you mean is that if I create a yang tree in a yang file, it will 
ultimately translate into maximum two shards?
One for the operational and one for the configuration?

So for example elan.yang:
container elan-interface-forwarding-entries {
config false;

list elan-interface-mac {
key "elan-interface";
description "All the MAC addresses learned on a particular elan 
interface";
max-elements "unbounded";
min-elements "0";
leaf elan-interface {
type leafref {
path "/if:interfaces/if:interface/if:name";
}
}

uses forwarding-entries;
}
}

container elan-tag-name-map {
config false;

list elan-tag-name {
key elan-tag;
leaf elan-tag {
type uint32;
}

leaf name {
type string;
description
"The name of the elan-instance.";
}
}
}

These 2 only live in the operational (Because config false), so it means 2 
Shards ?

-Original Message-
From: Robert Varga [mailto:n...@hq.sk]
Sent: Wednesday, January 11, 2017 4:45 PM
To: Sela, Guy mailto:guy.s...@hpe.com>>; Tom Pantelis 
mailto:tompante...@gmail.com>>; Kochba, Alon 
mailto:alo...@hpe.com>>
Cc: Williams, Marcus 
mailto:marcus.willi...@intel.com>>; Daniel Farrell 
mailto:dfarr...@redhat.com>>; odl netvirt dev 
mailto:netvirt-...@lists.opendaylight.org>>;
 
controller-dev@lists.opendaylight.org;
 
integration-...@lists.opendaylight.org
Subject: Re: [netvirt-dev] [controller-dev] [mdsal-dev] Netvirt Scale tests: 
OutOfMemory from datastore
On 01/11/2017 03:42 PM, Sela, Guy wrote:
> I have some blurriness about what a shard is, that I still didn’t
> figure out.
>
> I have some guesses:
>
> 1)  Every yang tree == one shard.
>
> 2)  Shard can be a collection of a number of yang trees.
>
> 3)  None of the above?
>

Mostly 1. Each shard encapsulates a single ShardDataTree, which encapsulates a 
single DataTree. The sum of shards is presented as the data store (CDS).

Regards,
Robert

___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: OutOfMemory from datastore

2017-01-11 Thread Kochba, Alon 
+ Daniel and Marcus

Jumping in here with some questions..
Is the bottom line here that the whole config DS size cannot exceed 2GB or did 
I get something wrong?
Is it possible we never encountered such a scenario in the S3P performance 
tests done in Beryllium/Boron [1], or did something change in the behavior?

It seems that this limitation is extremely problematic for scale, and should be 
easily recreated by doing NetVirt scale tests (loading ~200 computes and 
creating a VM on each, or configuring a TZ for all of them manually).

I see 1800 OVSDB nodes were installed in [1], but not sure if any flows were 
configured on the OpenFlow side which might cause the DS to scale..
We also need to monitor what part of the DS is taking so much space - we might 
have redundant data being stored catching up space, but in any case projects 
would hit 2GB at some point.

[1] 
https://www.opendaylight.org/sites/www.opendaylight.org/files/odl_performancetechnicalreport_1-1_052716.pdf
--alon

From: netvirt-dev-boun...@lists.opendaylight.org 
[mailto:netvirt-dev-boun...@lists.opendaylight.org] On Behalf Of Sela, Guy
Sent: Wednesday, 11 January 2017 11:23
To: Tom Pantelis 
Cc: odl netvirt dev ; 
controller-dev@lists.opendaylight.org; Robert Varga 
Subject: Re: [netvirt-dev] [controller-dev] [mdsal-dev] Netvirt Scale tests: 
OutOfMemory from datastore

Opened a bug:
https://bugs.opendaylight.org/show_bug.cgi?id=7521


From: Tom Pantelis [mailto:tompante...@gmail.com]
Sent: Wednesday, January 11, 2017 1:06 AM
To: Sela, Guy mailto:guy.s...@hpe.com>>
Cc: Robert Varga mailto:n...@hq.sk>>; 
controller-dev@lists.opendaylight.org;
 odl netvirt dev 
mailto:netvirt-...@lists.opendaylight.org>>
Subject: Re: [controller-dev] [mdsal-dev] Netvirt Scale tests: OutOfMemory from 
datastore

operational won't snapshot if not persisted or replicated.

Can you open a bug for tracking?

On Tue, Jan 10, 2017 at 4:12 PM, Sela, Guy 
mailto:guy.s...@hpe.com>> wrote:
Do the snapshot happen only to the configuration data store or to the 
operational as well?

-Original Message-
From: Robert Varga [mailto:n...@hq.sk]
Sent: Tuesday, January 10, 2017 10:21 PM
To: Tom Pantelis mailto:tompante...@gmail.com>>; Sela, 
Guy mailto:guy.s...@hpe.com>>
Cc: 
controller-dev@lists.opendaylight.org;
 odl netvirt dev 
mailto:netvirt-...@lists.opendaylight.org>>
Subject: Re: [controller-dev] [mdsal-dev] Netvirt Scale tests: OutOfMemory from 
datastore

On 01/10/2017 08:16 PM, Tom Pantelis wrote:
> Since the length field of an array is an int, it's constrained to
> Integer.MAX_VALUE (~2G). To handle snapshots larger than 2G we'll have
> to chuck it into multiple byte[].

That could get funky on the reassembly side of things. If we go that route, we 
may as well switch to something more friendly, like java.nio.ByteBuffer(), too.

Guy, just out of curiosity: how much duplication is in your data set?

Regards,
Robert

___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: OutOfMemory from datastore

2017-01-12 Thread Muthukumaran K 
Hi Sela,

There are 3 related aspects viz., module  - yang tree / yang module, shards – a 
group of yang trees whose data is placed together, sharding strategy – how 
trees and shards are related.

Default strategy in ODL is module-level. By that virtue, we can control to the 
extent of mapping one yang module to one shard.

When Tom says that everything else goes into default shard, it’s the built in 
behavior of the sharding and not user controllable. So, at user-controllable 
level its 1:1 --> module:shard and whatever module not configured by user with 
dedicated shard will go into default shard.

Effectively, by default, we would have inventory X 2 + topology X 2 + default X 
2 + toaster X 2 + EOS Shard (implicit and not configured) X 1 = 9 shards will 
be there in the system. Here 2 implies one for oper and one for config

This section describes the default behavior - 
https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Architecture:Clustering#Configuration


Regards

From: controller-dev-boun...@lists.opendaylight.org 
[mailto:controller-dev-boun...@lists.opendaylight.org] On Behalf Of Sela, Guy
Sent: Wednesday, January 11, 2017 8:37 PM
To: Tom Pantelis 
Cc: odl netvirt dev ; Kochba, Alon 
; integration-...@lists.opendaylight.org; 
controller-dev@lists.opendaylight.org
Subject: Re: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: 
OutOfMemory from datastore

Oh so that’s really different than option 1 I wrote.
You are saying that I have a capability of creating shards by taking different 
yang trees and combining them into shards?.
My smallest unit of work is a yang tree ?

I still don’t see how it is done.
Let’s say I wanted to take the 2 trees in my example and put them in one shard 
only for them.
How will module-shards.conf look like and how will modules.conf will look like?
If you have an example of that in some WIKI, you can just point me to that.


From: Tom Pantelis [mailto:tompante...@gmail.com]
Sent: Wednesday, January 11, 2017 4:58 PM
To: Sela, Guy mailto:guy.s...@hpe.com>>
Cc: Robert Varga mailto:n...@hq.sk>>; Kochba, Alon 
mailto:alo...@hpe.com>>; Williams, Marcus 
mailto:marcus.willi...@intel.com>>; Daniel Farrell 
mailto:dfarr...@redhat.com>>; odl netvirt dev 
mailto:netvirt-...@lists.opendaylight.org>>;
 
controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>;
 
integration-...@lists.opendaylight.org<mailto:integration-...@lists.opendaylight.org>
Subject: Re: [netvirt-dev] [controller-dev] [mdsal-dev] Netvirt Scale tests: 
OutOfMemory from datastore

Shards are (currently) statically configured in module-shards.conf. There's 3 
OOB - "topology", "inventory", and "default". Anything not under topology and 
inventory go into the default shard.

On Wed, Jan 11, 2017 at 9:51 AM, Sela, Guy 
mailto:guy.s...@hpe.com>> wrote:
So what you mean is that if I create a yang tree in a yang file, it will 
ultimately translate into maximum two shards?
One for the operational and one for the configuration?

So for example elan.yang:
container elan-interface-forwarding-entries {
config false;

list elan-interface-mac {
key "elan-interface";
description "All the MAC addresses learned on a particular elan 
interface";
max-elements "unbounded";
min-elements "0";
leaf elan-interface {
type leafref {
path "/if:interfaces/if:interface/if:name";
}
}

uses forwarding-entries;
}
}

container elan-tag-name-map {
config false;

list elan-tag-name {
key elan-tag;
leaf elan-tag {
type uint32;
}

leaf name {
type string;
description
"The name of the elan-instance.";
}
}
}

These 2 only live in the operational (Because config false), so it means 2 
Shards ?

-Original Message-
From: Robert Varga [mailto:n...@hq.sk<mailto:n...@hq.sk>]
Sent: Wednesday, January 11, 2017 4:45 PM
To: Sela, Guy mailto:guy.s...@hpe.com>>; Tom Pantelis 
mailto:tompante...@gmail.com>>; Kochba, Alon 
mailto:alo...@hpe.com>>
Cc: Williams, Marcus 
mailto:marcus.willi...@intel.com>>; Daniel Farrell 
mailto:dfarr...@redhat.com>>; odl netvirt dev 
mailto:netvirt-...@lists.opendaylight.org>>;
 
controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>;
 
integration-...@lists.opendaylight.org<mailto:integration-...@lists.opendaylight.org>
Subject: Re: [netvirt-dev] [controller-dev] [mdsal-dev] Netvirt Scale tests: 
OutOfMemory from datastore
On 01/11/2017 03:42 PM, Sela, Guy wrote:
> I have some blurriness about what a shard is, that

Re: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: OutOfMemory from datastore

2017-01-12 Thread Sela, Guy 
Thanks for the explanation, I finally understand.
I will print this reply and paste it next to my computer☺

So getting back to my bug prone question, I remember Robert saying in Seattle 
that you shouldn’t write in the same transaction to different shards. Because 
you can’t know in the code how will the final sharding be configured, would you 
say as a good practice to avoid writing to different yang modules in the same 
transaction?

From: Muthukumaran K [mailto:muthukumara...@ericsson.com]
Sent: Thursday, January 12, 2017 11:08 AM
To: Sela, Guy ; Tom Pantelis 
Cc: odl netvirt dev ; Kochba, Alon 
; integration-...@lists.opendaylight.org; 
controller-dev@lists.opendaylight.org
Subject: RE: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: 
OutOfMemory from datastore

Hi Sela,

There are 3 related aspects viz., module  - yang tree / yang module, shards – a 
group of yang trees whose data is placed together, sharding strategy – how 
trees and shards are related.

Default strategy in ODL is module-level. By that virtue, we can control to the 
extent of mapping one yang module to one shard.

When Tom says that everything else goes into default shard, it’s the built in 
behavior of the sharding and not user controllable. So, at user-controllable 
level its 1:1 --> module:shard and whatever module not configured by user with 
dedicated shard will go into default shard.

Effectively, by default, we would have inventory X 2 + topology X 2 + default X 
2 + toaster X 2 + EOS Shard (implicit and not configured) X 1 = 9 shards will 
be there in the system. Here 2 implies one for oper and one for config

This section describes the default behavior - 
https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Architecture:Clustering#Configuration


Regards


From: 
controller-dev-boun...@lists.opendaylight.org<mailto:controller-dev-boun...@lists.opendaylight.org>
 [mailto:controller-dev-boun...@lists.opendaylight.org] On Behalf Of Sela, Guy
Sent: Wednesday, January 11, 2017 8:37 PM
To: Tom Pantelis mailto:tompante...@gmail.com>>
Cc: odl netvirt dev 
mailto:netvirt-...@lists.opendaylight.org>>;
 Kochba, Alon mailto:alo...@hpe.com>>; 
integration-...@lists.opendaylight.org<mailto:integration-...@lists.opendaylight.org>;
 
controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>
Subject: Re: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: 
OutOfMemory from datastore

Oh so that’s really different than option 1 I wrote.
You are saying that I have a capability of creating shards by taking different 
yang trees and combining them into shards?.
My smallest unit of work is a yang tree ?

I still don’t see how it is done.
Let’s say I wanted to take the 2 trees in my example and put them in one shard 
only for them.
How will module-shards.conf look like and how will modules.conf will look like?
If you have an example of that in some WIKI, you can just point me to that.


From: Tom Pantelis [mailto:tompante...@gmail.com]
Sent: Wednesday, January 11, 2017 4:58 PM
To: Sela, Guy mailto:guy.s...@hpe.com>>
Cc: Robert Varga mailto:n...@hq.sk>>; Kochba, Alon 
mailto:alo...@hpe.com>>; Williams, Marcus 
mailto:marcus.willi...@intel.com>>; Daniel Farrell 
mailto:dfarr...@redhat.com>>; odl netvirt dev 
mailto:netvirt-...@lists.opendaylight.org>>;
 
controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>;
 
integration-...@lists.opendaylight.org<mailto:integration-...@lists.opendaylight.org>
Subject: Re: [netvirt-dev] [controller-dev] [mdsal-dev] Netvirt Scale tests: 
OutOfMemory from datastore

Shards are (currently) statically configured in module-shards.conf. There's 3 
OOB - "topology", "inventory", and "default". Anything not under topology and 
inventory go into the default shard.

On Wed, Jan 11, 2017 at 9:51 AM, Sela, Guy 
mailto:guy.s...@hpe.com>> wrote:
So what you mean is that if I create a yang tree in a yang file, it will 
ultimately translate into maximum two shards?
One for the operational and one for the configuration?

So for example elan.yang:
container elan-interface-forwarding-entries {
config false;

list elan-interface-mac {
key "elan-interface";
description "All the MAC addresses learned on a particular elan 
interface";
max-elements "unbounded";
min-elements "0";
leaf elan-interface {
type leafref {
path "/if:interfaces/if:interface/if:name";
}
}

uses forwarding-entries;
}
}

container elan-tag-name-map {
config false;

list elan-tag-name {
key elan-tag;
leaf elan-tag {
type uint32;
}

leaf name {

Re: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: OutOfMemory from datastore

2017-01-12 Thread Muthukumaran K 
Hi Sela,

Transaction is wrt a shard. So, if we take Netvirt for example, all the config 
yang modules get mapped to default config shard. So, its ok to have a single 
config transaction spanning multiple yang models

But if you are configuring a flow (which maps to Inventory-Config Shard) and 
also some tunnel config (which could be part of default-config shard) in same 
transaction, then we cross the shard boundaries and what Robert says hold true 
for that case.

Regards
Muthu


From: Sela, Guy [mailto:guy.s...@hpe.com]
Sent: Thursday, January 12, 2017 2:53 PM
To: Muthukumaran K ; Tom Pantelis 

Cc: odl netvirt dev ; Kochba, Alon 
; integration-...@lists.opendaylight.org; 
controller-dev@lists.opendaylight.org
Subject: RE: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: 
OutOfMemory from datastore

Thanks for the explanation, I finally understand.
I will print this reply and paste it next to my computer☺

So getting back to my bug prone question, I remember Robert saying in Seattle 
that you shouldn’t write in the same transaction to different shards. Because 
you can’t know in the code how will the final sharding be configured, would you 
say as a good practice to avoid writing to different yang modules in the same 
transaction?

From: Muthukumaran K [mailto:muthukumara...@ericsson.com]
Sent: Thursday, January 12, 2017 11:08 AM
To: Sela, Guy mailto:guy.s...@hpe.com>>; Tom Pantelis 
mailto:tompante...@gmail.com>>
Cc: odl netvirt dev 
mailto:netvirt-...@lists.opendaylight.org>>;
 Kochba, Alon mailto:alo...@hpe.com>>; 
integration-...@lists.opendaylight.org<mailto:integration-...@lists.opendaylight.org>;
 
controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>
Subject: RE: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: 
OutOfMemory from datastore

Hi Sela,

There are 3 related aspects viz., module  - yang tree / yang module, shards – a 
group of yang trees whose data is placed together, sharding strategy – how 
trees and shards are related.

Default strategy in ODL is module-level. By that virtue, we can control to the 
extent of mapping one yang module to one shard.

When Tom says that everything else goes into default shard, it’s the built in 
behavior of the sharding and not user controllable. So, at user-controllable 
level its 1:1 --> module:shard and whatever module not configured by user with 
dedicated shard will go into default shard.

Effectively, by default, we would have inventory X 2 + topology X 2 + default X 
2 + toaster X 2 + EOS Shard (implicit and not configured) X 1 = 9 shards will 
be there in the system. Here 2 implies one for oper and one for config

This section describes the default behavior - 
https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Architecture:Clustering#Configuration


Regards


From: 
controller-dev-boun...@lists.opendaylight.org<mailto:controller-dev-boun...@lists.opendaylight.org>
 [mailto:controller-dev-boun...@lists.opendaylight.org] On Behalf Of Sela, Guy
Sent: Wednesday, January 11, 2017 8:37 PM
To: Tom Pantelis mailto:tompante...@gmail.com>>
Cc: odl netvirt dev 
mailto:netvirt-...@lists.opendaylight.org>>;
 Kochba, Alon mailto:alo...@hpe.com>>; 
integration-...@lists.opendaylight.org<mailto:integration-...@lists.opendaylight.org>;
 
controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>
Subject: Re: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: 
OutOfMemory from datastore

Oh so that’s really different than option 1 I wrote.
You are saying that I have a capability of creating shards by taking different 
yang trees and combining them into shards?.
My smallest unit of work is a yang tree ?

I still don’t see how it is done.
Let’s say I wanted to take the 2 trees in my example and put them in one shard 
only for them.
How will module-shards.conf look like and how will modules.conf will look like?
If you have an example of that in some WIKI, you can just point me to that.


From: Tom Pantelis [mailto:tompante...@gmail.com]
Sent: Wednesday, January 11, 2017 4:58 PM
To: Sela, Guy mailto:guy.s...@hpe.com>>
Cc: Robert Varga mailto:n...@hq.sk>>; Kochba, Alon 
mailto:alo...@hpe.com>>; Williams, Marcus 
mailto:marcus.willi...@intel.com>>; Daniel Farrell 
mailto:dfarr...@redhat.com>>; odl netvirt dev 
mailto:netvirt-...@lists.opendaylight.org>>;
 
controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>;
 
integration-...@lists.opendaylight.org<mailto:integration-...@lists.opendaylight.org>
Subject: Re: [netvirt-dev] [controller-dev] [mdsal-dev] Netvirt Scale tests: 
OutOfMemory from datastore

Shards are (currently) statically configured in module-shards.conf. There's 3 
OOB - "topology", "inventory", and "default". Anything not under topology and 
inventory go in

Re: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: OutOfMemory from datastore

2017-01-12 Thread Vishal Thapar 
Hi Guy,

You can look at BatchingUtils in Genius that we use for InterfaceManager. Since 
all IFM data goes to TopologyConfig or Default config shard, we batch 
transactions separately. As of today we do know statically which yang model 
goes to which shard and we’re taking advantage of it to do batching in 
Genius/Netvirt.

Regards,
Vishal.

From: controller-dev-boun...@lists.opendaylight.org 
[mailto:controller-dev-boun...@lists.opendaylight.org] On Behalf Of 
Muthukumaran K
Sent: 12 January 2017 15:00
To: Sela, Guy ; Tom Pantelis 
Cc: odl netvirt dev ; 
controller-dev@lists.opendaylight.org; integration-...@lists.opendaylight.org; 
Kochba, Alon 
Subject: Re: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: 
OutOfMemory from datastore

Hi Sela,

Transaction is wrt a shard. So, if we take Netvirt for example, all the config 
yang modules get mapped to default config shard. So, its ok to have a single 
config transaction spanning multiple yang models

But if you are configuring a flow (which maps to Inventory-Config Shard) and 
also some tunnel config (which could be part of default-config shard) in same 
transaction, then we cross the shard boundaries and what Robert says hold true 
for that case.

Regards
Muthu


From: Sela, Guy [mailto:guy.s...@hpe.com]
Sent: Thursday, January 12, 2017 2:53 PM
To: Muthukumaran K 
mailto:muthukumara...@ericsson.com>>; Tom Pantelis 
mailto:tompante...@gmail.com>>
Cc: odl netvirt dev 
mailto:netvirt-...@lists.opendaylight.org>>;
 Kochba, Alon mailto:alo...@hpe.com>>; 
integration-...@lists.opendaylight.org<mailto:integration-...@lists.opendaylight.org>;
 
controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>
Subject: RE: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: 
OutOfMemory from datastore

Thanks for the explanation, I finally understand.
I will print this reply and paste it next to my computer☺

So getting back to my bug prone question, I remember Robert saying in Seattle 
that you shouldn’t write in the same transaction to different shards. Because 
you can’t know in the code how will the final sharding be configured, would you 
say as a good practice to avoid writing to different yang modules in the same 
transaction?

From: Muthukumaran K [mailto:muthukumara...@ericsson.com]
Sent: Thursday, January 12, 2017 11:08 AM
To: Sela, Guy mailto:guy.s...@hpe.com>>; Tom Pantelis 
mailto:tompante...@gmail.com>>
Cc: odl netvirt dev 
mailto:netvirt-...@lists.opendaylight.org>>;
 Kochba, Alon mailto:alo...@hpe.com>>; 
integration-...@lists.opendaylight.org<mailto:integration-...@lists.opendaylight.org>;
 
controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>
Subject: RE: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: 
OutOfMemory from datastore

Hi Sela,

There are 3 related aspects viz., module  - yang tree / yang module, shards – a 
group of yang trees whose data is placed together, sharding strategy – how 
trees and shards are related.

Default strategy in ODL is module-level. By that virtue, we can control to the 
extent of mapping one yang module to one shard.

When Tom says that everything else goes into default shard, it’s the built in 
behavior of the sharding and not user controllable. So, at user-controllable 
level its 1:1 --> module:shard and whatever module not configured by user with 
dedicated shard will go into default shard.

Effectively, by default, we would have inventory X 2 + topology X 2 + default X 
2 + toaster X 2 + EOS Shard (implicit and not configured) X 1 = 9 shards will 
be there in the system. Here 2 implies one for oper and one for config

This section describes the default behavior - 
https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Architecture:Clustering#Configuration


Regards


From: 
controller-dev-boun...@lists.opendaylight.org<mailto:controller-dev-boun...@lists.opendaylight.org>
 [mailto:controller-dev-boun...@lists.opendaylight.org] On Behalf Of Sela, Guy
Sent: Wednesday, January 11, 2017 8:37 PM
To: Tom Pantelis mailto:tompante...@gmail.com>>
Cc: odl netvirt dev 
mailto:netvirt-...@lists.opendaylight.org>>;
 Kochba, Alon mailto:alo...@hpe.com>>; 
integration-...@lists.opendaylight.org<mailto:integration-...@lists.opendaylight.org>;
 
controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>
Subject: Re: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: 
OutOfMemory from datastore

Oh so that’s really different than option 1 I wrote.
You are saying that I have a capability of creating shards by taking different 
yang trees and combining them into shards?.
My smallest unit of work is a yang tree ?

I still don’t see how it is done.
Let’s say I wanted to take the 2 trees in my example and put them in one shard 
only for them.
How will module-shards.conf look like

Re: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: OutOfMemory from datastore

2017-01-12 Thread Sela, Guy 
Shards configuration is just configuration, and can be determined in the 
installation/distribution of the product.
The code is always the same code.
One distribution could decide to split the netvirt modules into 3 shards, and a 
different could decide to leave everything in the default shard.
If I want to be safe while writing the code I have to consider the “worst 
case”, and assume that potentially my module is in a shard of its own.
Unless you want to say that  the shard configuration file should never be 
touched?

From: Muthukumaran K [mailto:muthukumara...@ericsson.com]
Sent: Thursday, January 12, 2017 11:30 AM
To: Sela, Guy ; Tom Pantelis 
Cc: odl netvirt dev ; Kochba, Alon 
; integration-...@lists.opendaylight.org; 
controller-dev@lists.opendaylight.org
Subject: RE: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: 
OutOfMemory from datastore

Hi Sela,

Transaction is wrt a shard. So, if we take Netvirt for example, all the config 
yang modules get mapped to default config shard. So, its ok to have a single 
config transaction spanning multiple yang models

But if you are configuring a flow (which maps to Inventory-Config Shard) and 
also some tunnel config (which could be part of default-config shard) in same 
transaction, then we cross the shard boundaries and what Robert says hold true 
for that case.

Regards
Muthu


From: Sela, Guy [mailto:guy.s...@hpe.com]
Sent: Thursday, January 12, 2017 2:53 PM
To: Muthukumaran K 
mailto:muthukumara...@ericsson.com>>; Tom Pantelis 
mailto:tompante...@gmail.com>>
Cc: odl netvirt dev 
mailto:netvirt-...@lists.opendaylight.org>>;
 Kochba, Alon mailto:alo...@hpe.com>>; 
integration-...@lists.opendaylight.org<mailto:integration-...@lists.opendaylight.org>;
 
controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>
Subject: RE: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: 
OutOfMemory from datastore

Thanks for the explanation, I finally understand.
I will print this reply and paste it next to my computer☺

So getting back to my bug prone question, I remember Robert saying in Seattle 
that you shouldn’t write in the same transaction to different shards. Because 
you can’t know in the code how will the final sharding be configured, would you 
say as a good practice to avoid writing to different yang modules in the same 
transaction?

From: Muthukumaran K [mailto:muthukumara...@ericsson.com]
Sent: Thursday, January 12, 2017 11:08 AM
To: Sela, Guy mailto:guy.s...@hpe.com>>; Tom Pantelis 
mailto:tompante...@gmail.com>>
Cc: odl netvirt dev 
mailto:netvirt-...@lists.opendaylight.org>>;
 Kochba, Alon mailto:alo...@hpe.com>>; 
integration-...@lists.opendaylight.org<mailto:integration-...@lists.opendaylight.org>;
 
controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>
Subject: RE: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: 
OutOfMemory from datastore

Hi Sela,

There are 3 related aspects viz., module  - yang tree / yang module, shards – a 
group of yang trees whose data is placed together, sharding strategy – how 
trees and shards are related.

Default strategy in ODL is module-level. By that virtue, we can control to the 
extent of mapping one yang module to one shard.

When Tom says that everything else goes into default shard, it’s the built in 
behavior of the sharding and not user controllable. So, at user-controllable 
level its 1:1 --> module:shard and whatever module not configured by user with 
dedicated shard will go into default shard.

Effectively, by default, we would have inventory X 2 + topology X 2 + default X 
2 + toaster X 2 + EOS Shard (implicit and not configured) X 1 = 9 shards will 
be there in the system. Here 2 implies one for oper and one for config

This section describes the default behavior - 
https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Architecture:Clustering#Configuration


Regards


From: 
controller-dev-boun...@lists.opendaylight.org<mailto:controller-dev-boun...@lists.opendaylight.org>
 [mailto:controller-dev-boun...@lists.opendaylight.org] On Behalf Of Sela, Guy
Sent: Wednesday, January 11, 2017 8:37 PM
To: Tom Pantelis mailto:tompante...@gmail.com>>
Cc: odl netvirt dev 
mailto:netvirt-...@lists.opendaylight.org>>;
 Kochba, Alon mailto:alo...@hpe.com>>; 
integration-...@lists.opendaylight.org<mailto:integration-...@lists.opendaylight.org>;
 
controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>
Subject: Re: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: 
OutOfMemory from datastore

Oh so that’s really different than option 1 I wrote.
You are saying that I have a capability of creating shards by taking different 
yang trees and combining them into shards?.
My smallest unit of work is a yang tree ?

I still don’t see how it is done.
Let’s say I want

Re: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: OutOfMemory from datastore

2017-01-12 Thread Sela, Guy 
Hi,

I’ll use the same argument that I gave to Muthu:
“
Shards configuration is just configuration, and can be determined in the 
installation/distribution of the product.
The code is always the same code.
One distribution could decide to split the netvirt modules into 3 shards, and a 
different could decide to leave everything in the default shard.
If I want to be safe while writing the code I have to consider the “worst 
case”, and assume that potentially my module is in a shard of its own.
Unless you want to say that  the shard configuration file should never be 
touched?
“

From: Vishal Thapar [mailto:vishal.tha...@ericsson.com]
Sent: Thursday, January 12, 2017 12:18 PM
To: Muthukumaran K ; Sela, Guy ; 
Tom Pantelis 
Cc: odl netvirt dev ; 
controller-dev@lists.opendaylight.org; integration-...@lists.opendaylight.org; 
Kochba, Alon 
Subject: RE: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: 
OutOfMemory from datastore

Hi Guy,

You can look at BatchingUtils in Genius that we use for InterfaceManager. Since 
all IFM data goes to TopologyConfig or Default config shard, we batch 
transactions separately. As of today we do know statically which yang model 
goes to which shard and we’re taking advantage of it to do batching in 
Genius/Netvirt.

Regards,
Vishal.

From: 
controller-dev-boun...@lists.opendaylight.org<mailto:controller-dev-boun...@lists.opendaylight.org>
 [mailto:controller-dev-boun...@lists.opendaylight.org] On Behalf Of 
Muthukumaran K
Sent: 12 January 2017 15:00
To: Sela, Guy mailto:guy.s...@hpe.com>>; Tom Pantelis 
mailto:tompante...@gmail.com>>
Cc: odl netvirt dev 
mailto:netvirt-...@lists.opendaylight.org>>;
 
controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>;
 
integration-...@lists.opendaylight.org<mailto:integration-...@lists.opendaylight.org>;
 Kochba, Alon mailto:alo...@hpe.com>>
Subject: Re: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: 
OutOfMemory from datastore

Hi Sela,

Transaction is wrt a shard. So, if we take Netvirt for example, all the config 
yang modules get mapped to default config shard. So, its ok to have a single 
config transaction spanning multiple yang models

But if you are configuring a flow (which maps to Inventory-Config Shard) and 
also some tunnel config (which could be part of default-config shard) in same 
transaction, then we cross the shard boundaries and what Robert says hold true 
for that case.

Regards
Muthu


From: Sela, Guy [mailto:guy.s...@hpe.com]
Sent: Thursday, January 12, 2017 2:53 PM
To: Muthukumaran K 
mailto:muthukumara...@ericsson.com>>; Tom Pantelis 
mailto:tompante...@gmail.com>>
Cc: odl netvirt dev 
mailto:netvirt-...@lists.opendaylight.org>>;
 Kochba, Alon mailto:alo...@hpe.com>>; 
integration-...@lists.opendaylight.org<mailto:integration-...@lists.opendaylight.org>;
 
controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>
Subject: RE: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: 
OutOfMemory from datastore

Thanks for the explanation, I finally understand.
I will print this reply and paste it next to my computer☺

So getting back to my bug prone question, I remember Robert saying in Seattle 
that you shouldn’t write in the same transaction to different shards. Because 
you can’t know in the code how will the final sharding be configured, would you 
say as a good practice to avoid writing to different yang modules in the same 
transaction?

From: Muthukumaran K [mailto:muthukumara...@ericsson.com]
Sent: Thursday, January 12, 2017 11:08 AM
To: Sela, Guy mailto:guy.s...@hpe.com>>; Tom Pantelis 
mailto:tompante...@gmail.com>>
Cc: odl netvirt dev 
mailto:netvirt-...@lists.opendaylight.org>>;
 Kochba, Alon mailto:alo...@hpe.com>>; 
integration-...@lists.opendaylight.org<mailto:integration-...@lists.opendaylight.org>;
 
controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>
Subject: RE: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: 
OutOfMemory from datastore

Hi Sela,

There are 3 related aspects viz., module  - yang tree / yang module, shards – a 
group of yang trees whose data is placed together, sharding strategy – how 
trees and shards are related.

Default strategy in ODL is module-level. By that virtue, we can control to the 
extent of mapping one yang module to one shard.

When Tom says that everything else goes into default shard, it’s the built in 
behavior of the sharding and not user controllable. So, at user-controllable 
level its 1:1 --> module:shard and whatever module not configured by user with 
dedicated shard will go into default shard.

Effectively, by default, we would have inventory X 2 + topology X 2 + default X 
2 + toaster X 2 + EOS Shard (implicit and not configured) X 1 = 9 shards will 
be there in the system. Here 2 impli

Re: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: OutOfMemory from datastore

2017-01-12 Thread Muthukumaran K 
Hi Sela,

>>> Transaction is wrt a shard

As an afterthought, from databroker perspective, while creating a transaction, 
we do not tie it up with a yang-instance-identifier. Its only the operations 
within the transaction reflects the same. So, contract itself does not impose 
this (I vaguely recollect that Sela had brought this up sometime in September 
2016 and Tom and Robert had a good explanation in [1].

So, its more of usage discipline.

[1] - 
https://lists.opendaylight.org/pipermail/controller-dev/2016-September/012646.html

One more thing, if you want to look at the config and operational shards in 
controller, JConsole or its access via Jolokia is a good way to check the same.
Via Jolokia, following URLs give the same

how do I find the list of Operational Shards
HTTP GET http://:8181/jolokia/read/ org.opendaylight.controller: 
Category=ShardManager,name=shard-manager-operational, 
type=DistributedOperationalDataStore 
<http://%3ccontroller-ip%3e:8181/jolokia/read/%20org.opendaylight.controller:%20Category=ShardManager,name=shard-manager-operational,%20type=DistributedOperationalDataStore%20>

So, how do I find the list of Config Shards
HTTP GET http://:8181/jolokia/read/ org.opendaylight.controller: 
Category=ShardManager,name=shard-manager-config, 
type=DistributedConfigDataStore 
<http://%3cPL-Node-IP-address%3e:8181/jolokia/read/%20org.opendaylight.controller:%20Category=ShardManager,name=shard-manager-config,%20type=DistributedConfigDataStore%20>


Regards
Muthu


From: Vishal Thapar
Sent: Thursday, January 12, 2017 3:48 PM
To: Muthukumaran K ; Sela, Guy ; 
Tom Pantelis 
Cc: odl netvirt dev ; 
controller-dev@lists.opendaylight.org; integration-...@lists.opendaylight.org; 
Kochba, Alon 
Subject: RE: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: 
OutOfMemory from datastore

Hi Guy,

You can look at BatchingUtils in Genius that we use for InterfaceManager. Since 
all IFM data goes to TopologyConfig or Default config shard, we batch 
transactions separately. As of today we do know statically which yang model 
goes to which shard and we’re taking advantage of it to do batching in 
Genius/Netvirt.

Regards,
Vishal.

From: 
controller-dev-boun...@lists.opendaylight.org<mailto:controller-dev-boun...@lists.opendaylight.org>
 [mailto:controller-dev-boun...@lists.opendaylight.org] On Behalf Of 
Muthukumaran K
Sent: 12 January 2017 15:00
To: Sela, Guy mailto:guy.s...@hpe.com>>; Tom Pantelis 
mailto:tompante...@gmail.com>>
Cc: odl netvirt dev 
mailto:netvirt-...@lists.opendaylight.org>>;
 
controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>;
 
integration-...@lists.opendaylight.org<mailto:integration-...@lists.opendaylight.org>;
 Kochba, Alon mailto:alo...@hpe.com>>
Subject: Re: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: 
OutOfMemory from datastore

Hi Sela,

Transaction is wrt a shard. So, if we take Netvirt for example, all the config 
yang modules get mapped to default config shard. So, its ok to have a single 
config transaction spanning multiple yang models

But if you are configuring a flow (which maps to Inventory-Config Shard) and 
also some tunnel config (which could be part of default-config shard) in same 
transaction, then we cross the shard boundaries and what Robert says hold true 
for that case.

Regards
Muthu


From: Sela, Guy [mailto:guy.s...@hpe.com]
Sent: Thursday, January 12, 2017 2:53 PM
To: Muthukumaran K 
mailto:muthukumara...@ericsson.com>>; Tom Pantelis 
mailto:tompante...@gmail.com>>
Cc: odl netvirt dev 
mailto:netvirt-...@lists.opendaylight.org>>;
 Kochba, Alon mailto:alo...@hpe.com>>; 
integration-...@lists.opendaylight.org<mailto:integration-...@lists.opendaylight.org>;
 
controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>
Subject: RE: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: 
OutOfMemory from datastore

Thanks for the explanation, I finally understand.
I will print this reply and paste it next to my computer☺

So getting back to my bug prone question, I remember Robert saying in Seattle 
that you shouldn’t write in the same transaction to different shards. Because 
you can’t know in the code how will the final sharding be configured, would you 
say as a good practice to avoid writing to different yang modules in the same 
transaction?

From: Muthukumaran K [mailto:muthukumara...@ericsson.com]
Sent: Thursday, January 12, 2017 11:08 AM
To: Sela, Guy mailto:guy.s...@hpe.com>>; Tom Pantelis 
mailto:tompante...@gmail.com>>
Cc: odl netvirt dev 
mailto:netvirt-...@lists.opendaylight.org>>;
 Kochba, Alon mailto:alo...@hpe.com>>; 
integration-...@lists.opendaylight.org<mailto:integration-...@lists.opendaylight.org>;
 
controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>
Subject: RE: [control

Re: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: OutOfMemory from datastore

2017-01-12 Thread Sela, Guy 
Thanks.

From the talk Robert gave in Seattle I remember he said that writing to 
multiple shards in a single transaction can cause data corruption.

From: Muthukumaran K [mailto:muthukumara...@ericsson.com]
Sent: Thursday, January 12, 2017 12:53 PM
To: Vishal Thapar ; Sela, Guy ; 
Tom Pantelis 
Cc: odl netvirt dev ; 
controller-dev@lists.opendaylight.org; integration-...@lists.opendaylight.org; 
Kochba, Alon 
Subject: RE: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: 
OutOfMemory from datastore

Hi Sela,

>>> Transaction is wrt a shard

As an afterthought, from databroker perspective, while creating a transaction, 
we do not tie it up with a yang-instance-identifier. Its only the operations 
within the transaction reflects the same. So, contract itself does not impose 
this (I vaguely recollect that Sela had brought this up sometime in September 
2016 and Tom and Robert had a good explanation in [1].

So, its more of usage discipline.

[1] - 
https://lists.opendaylight.org/pipermail/controller-dev/2016-September/012646.html

One more thing, if you want to look at the config and operational shards in 
controller, JConsole or its access via Jolokia is a good way to check the same.
Via Jolokia, following URLs give the same

how do I find the list of Operational Shards
HTTP GET http://:8181/jolokia/read/ org.opendaylight.controller: 
Category=ShardManager,name=shard-manager-operational, 
type=DistributedOperationalDataStore 
<http://%3ccontroller-ip%3e:8181/jolokia/read/%20org.opendaylight.controller:%20Category=ShardManager,name=shard-manager-operational,%20type=DistributedOperationalDataStore%20>

So, how do I find the list of Config Shards
HTTP GET http://:8181/jolokia/read/ org.opendaylight.controller: 
Category=ShardManager,name=shard-manager-config, 
type=DistributedConfigDataStore 
<http://%3cPL-Node-IP-address%3e:8181/jolokia/read/%20org.opendaylight.controller:%20Category=ShardManager,name=shard-manager-config,%20type=DistributedConfigDataStore%20>


Regards
Muthu


From: Vishal Thapar
Sent: Thursday, January 12, 2017 3:48 PM
To: Muthukumaran K 
mailto:muthukumara...@ericsson.com>>; Sela, Guy 
mailto:guy.s...@hpe.com>>; Tom Pantelis 
mailto:tompante...@gmail.com>>
Cc: odl netvirt dev 
mailto:netvirt-...@lists.opendaylight.org>>;
 
controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>;
 
integration-...@lists.opendaylight.org<mailto:integration-...@lists.opendaylight.org>;
 Kochba, Alon mailto:alo...@hpe.com>>
Subject: RE: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: 
OutOfMemory from datastore

Hi Guy,

You can look at BatchingUtils in Genius that we use for InterfaceManager. Since 
all IFM data goes to TopologyConfig or Default config shard, we batch 
transactions separately. As of today we do know statically which yang model 
goes to which shard and we’re taking advantage of it to do batching in 
Genius/Netvirt.

Regards,
Vishal.

From: 
controller-dev-boun...@lists.opendaylight.org<mailto:controller-dev-boun...@lists.opendaylight.org>
 [mailto:controller-dev-boun...@lists.opendaylight.org] On Behalf Of 
Muthukumaran K
Sent: 12 January 2017 15:00
To: Sela, Guy mailto:guy.s...@hpe.com>>; Tom Pantelis 
mailto:tompante...@gmail.com>>
Cc: odl netvirt dev 
mailto:netvirt-...@lists.opendaylight.org>>;
 
controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>;
 
integration-...@lists.opendaylight.org<mailto:integration-...@lists.opendaylight.org>;
 Kochba, Alon mailto:alo...@hpe.com>>
Subject: Re: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: 
OutOfMemory from datastore

Hi Sela,

Transaction is wrt a shard. So, if we take Netvirt for example, all the config 
yang modules get mapped to default config shard. So, its ok to have a single 
config transaction spanning multiple yang models

But if you are configuring a flow (which maps to Inventory-Config Shard) and 
also some tunnel config (which could be part of default-config shard) in same 
transaction, then we cross the shard boundaries and what Robert says hold true 
for that case.

Regards
Muthu


From: Sela, Guy [mailto:guy.s...@hpe.com]
Sent: Thursday, January 12, 2017 2:53 PM
To: Muthukumaran K 
mailto:muthukumara...@ericsson.com>>; Tom Pantelis 
mailto:tompante...@gmail.com>>
Cc: odl netvirt dev 
mailto:netvirt-...@lists.opendaylight.org>>;
 Kochba, Alon mailto:alo...@hpe.com>>; 
integration-...@lists.opendaylight.org<mailto:integration-...@lists.opendaylight.org>;
 
controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>
Subject: RE: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: 
OutOfMemory from datastore

Thanks for the explanation, I finally understand.
I will print this reply and paste it next to my computer☺

So getting back to my bug prone questi

Re: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: OutOfMemory from datastore

2017-01-12 Thread Muthukumaran K 
I fully agree Sela.

Shard configuration is a flexibility provided that can be used as deployment 
engineering work and a choice to be made as part of a module’s deployment plan. 
So, as it stands today, the earlier the decision of whether we dedicate a shard 
for our specific model is taken, we would be more cautious.

Of course, I am setting aside runtime resource aspect of creating too many 
shards (please note that every shard represents a mini RAFT instance by itself 
across the cluster)

Internal implementation is one and the same.

Regards
Muthu


From: Sela, Guy [mailto:guy.s...@hpe.com]
Sent: Thursday, January 12, 2017 4:21 PM
To: Vishal Thapar ; Muthukumaran K 
; Tom Pantelis 
Cc: odl netvirt dev ; 
controller-dev@lists.opendaylight.org; integration-...@lists.opendaylight.org; 
Kochba, Alon 
Subject: RE: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: 
OutOfMemory from datastore

Hi,

I’ll use the same argument that I gave to Muthu:
“
Shards configuration is just configuration, and can be determined in the 
installation/distribution of the product.
The code is always the same code.
One distribution could decide to split the netvirt modules into 3 shards, and a 
different could decide to leave everything in the default shard.
If I want to be safe while writing the code I have to consider the “worst 
case”, and assume that potentially my module is in a shard of its own.
Unless you want to say that  the shard configuration file should never be 
touched?
“

From: Vishal Thapar [mailto:vishal.tha...@ericsson.com]
Sent: Thursday, January 12, 2017 12:18 PM
To: Muthukumaran K 
mailto:muthukumara...@ericsson.com>>; Sela, Guy 
mailto:guy.s...@hpe.com>>; Tom Pantelis 
mailto:tompante...@gmail.com>>
Cc: odl netvirt dev 
mailto:netvirt-...@lists.opendaylight.org>>;
 
controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>;
 
integration-...@lists.opendaylight.org<mailto:integration-...@lists.opendaylight.org>;
 Kochba, Alon mailto:alo...@hpe.com>>
Subject: RE: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: 
OutOfMemory from datastore

Hi Guy,

You can look at BatchingUtils in Genius that we use for InterfaceManager. Since 
all IFM data goes to TopologyConfig or Default config shard, we batch 
transactions separately. As of today we do know statically which yang model 
goes to which shard and we’re taking advantage of it to do batching in 
Genius/Netvirt.

Regards,
Vishal.

From: 
controller-dev-boun...@lists.opendaylight.org<mailto:controller-dev-boun...@lists.opendaylight.org>
 [mailto:controller-dev-boun...@lists.opendaylight.org] On Behalf Of 
Muthukumaran K
Sent: 12 January 2017 15:00
To: Sela, Guy mailto:guy.s...@hpe.com>>; Tom Pantelis 
mailto:tompante...@gmail.com>>
Cc: odl netvirt dev 
mailto:netvirt-...@lists.opendaylight.org>>;
 
controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>;
 
integration-...@lists.opendaylight.org<mailto:integration-...@lists.opendaylight.org>;
 Kochba, Alon mailto:alo...@hpe.com>>
Subject: Re: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: 
OutOfMemory from datastore

Hi Sela,

Transaction is wrt a shard. So, if we take Netvirt for example, all the config 
yang modules get mapped to default config shard. So, its ok to have a single 
config transaction spanning multiple yang models

But if you are configuring a flow (which maps to Inventory-Config Shard) and 
also some tunnel config (which could be part of default-config shard) in same 
transaction, then we cross the shard boundaries and what Robert says hold true 
for that case.

Regards
Muthu


From: Sela, Guy [mailto:guy.s...@hpe.com]
Sent: Thursday, January 12, 2017 2:53 PM
To: Muthukumaran K 
mailto:muthukumara...@ericsson.com>>; Tom Pantelis 
mailto:tompante...@gmail.com>>
Cc: odl netvirt dev 
mailto:netvirt-...@lists.opendaylight.org>>;
 Kochba, Alon mailto:alo...@hpe.com>>; 
integration-...@lists.opendaylight.org<mailto:integration-...@lists.opendaylight.org>;
 
controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>
Subject: RE: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: 
OutOfMemory from datastore

Thanks for the explanation, I finally understand.
I will print this reply and paste it next to my computer☺

So getting back to my bug prone question, I remember Robert saying in Seattle 
that you shouldn’t write in the same transaction to different shards. Because 
you can’t know in the code how will the final sharding be configured, would you 
say as a good practice to avoid writing to different yang modules in the same 
transaction?

From: Muthukumaran K [mailto:muthukumara...@ericsson.com]
Sent: Thursday, January 12, 2017 11:08 AM
To: Sela, Guy mailto:guy.s...@hpe.com>>; Tom Pantelis 
mailto:tompante...@gmail.com>>
Cc: odl netv

Re: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: OutOfMemory from datastore

2017-01-12 Thread Sela, Guy 
IMO netvirt should already plan ahead to scale deployments, and assume that 
potentially high scale modules might reside in shards of their own, and code 
the transactions wrt that.
From my understanding, you currently assume that everything that is not 
inventory or topology is default shard, and you tie the destiny of potentially 
separated modules, into the same shard, by using the same write transactions.



From: Sela, Guy
Sent: Thursday, January 12, 2017 12:51 PM
To: 'Vishal Thapar' ; Muthukumaran K 
; Tom Pantelis 
Cc: odl netvirt dev ; 
controller-dev@lists.opendaylight.org; integration-...@lists.opendaylight.org; 
Kochba, Alon 
Subject: RE: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: 
OutOfMemory from datastore

Hi,

I’ll use the same argument that I gave to Muthu:
“
Shards configuration is just configuration, and can be determined in the 
installation/distribution of the product.
The code is always the same code.
One distribution could decide to split the netvirt modules into 3 shards, and a 
different could decide to leave everything in the default shard.
If I want to be safe while writing the code I have to consider the “worst 
case”, and assume that potentially my module is in a shard of its own.
Unless you want to say that  the shard configuration file should never be 
touched?
“

From: Vishal Thapar [mailto:vishal.tha...@ericsson.com]
Sent: Thursday, January 12, 2017 12:18 PM
To: Muthukumaran K 
mailto:muthukumara...@ericsson.com>>; Sela, Guy 
mailto:guy.s...@hpe.com>>; Tom Pantelis 
mailto:tompante...@gmail.com>>
Cc: odl netvirt dev 
mailto:netvirt-...@lists.opendaylight.org>>;
 
controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>;
 
integration-...@lists.opendaylight.org<mailto:integration-...@lists.opendaylight.org>;
 Kochba, Alon mailto:alo...@hpe.com>>
Subject: RE: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: 
OutOfMemory from datastore

Hi Guy,

You can look at BatchingUtils in Genius that we use for InterfaceManager. Since 
all IFM data goes to TopologyConfig or Default config shard, we batch 
transactions separately. As of today we do know statically which yang model 
goes to which shard and we’re taking advantage of it to do batching in 
Genius/Netvirt.

Regards,
Vishal.

From: 
controller-dev-boun...@lists.opendaylight.org<mailto:controller-dev-boun...@lists.opendaylight.org>
 [mailto:controller-dev-boun...@lists.opendaylight.org] On Behalf Of 
Muthukumaran K
Sent: 12 January 2017 15:00
To: Sela, Guy mailto:guy.s...@hpe.com>>; Tom Pantelis 
mailto:tompante...@gmail.com>>
Cc: odl netvirt dev 
mailto:netvirt-...@lists.opendaylight.org>>;
 
controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>;
 
integration-...@lists.opendaylight.org<mailto:integration-...@lists.opendaylight.org>;
 Kochba, Alon mailto:alo...@hpe.com>>
Subject: Re: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: 
OutOfMemory from datastore

Hi Sela,

Transaction is wrt a shard. So, if we take Netvirt for example, all the config 
yang modules get mapped to default config shard. So, its ok to have a single 
config transaction spanning multiple yang models

But if you are configuring a flow (which maps to Inventory-Config Shard) and 
also some tunnel config (which could be part of default-config shard) in same 
transaction, then we cross the shard boundaries and what Robert says hold true 
for that case.

Regards
Muthu


From: Sela, Guy [mailto:guy.s...@hpe.com]
Sent: Thursday, January 12, 2017 2:53 PM
To: Muthukumaran K 
mailto:muthukumara...@ericsson.com>>; Tom Pantelis 
mailto:tompante...@gmail.com>>
Cc: odl netvirt dev 
mailto:netvirt-...@lists.opendaylight.org>>;
 Kochba, Alon mailto:alo...@hpe.com>>; 
integration-...@lists.opendaylight.org<mailto:integration-...@lists.opendaylight.org>;
 
controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>
Subject: RE: [controller-dev] [netvirt-dev] [mdsal-dev] Netvirt Scale tests: 
OutOfMemory from datastore

Thanks for the explanation, I finally understand.
I will print this reply and paste it next to my computer☺

So getting back to my bug prone question, I remember Robert saying in Seattle 
that you shouldn’t write in the same transaction to different shards. Because 
you can’t know in the code how will the final sharding be configured, would you 
say as a good practice to avoid writing to different yang modules in the same 
transaction?

From: Muthukumaran K [mailto:muthukumara...@ericsson.com]
Sent: Thursday, January 12, 2017 11:08 AM
To: Sela, Guy mailto:guy.s...@hpe.com>>; Tom Pantelis 
mailto:tompante...@gmail.com>>
Cc: odl netvirt dev 
mailto:netvirt-...@lists.opendaylight.org>>;
 Kochba, Alon mailto:alo...@hpe.com>>; 
integration-...@lists.opendaylight.org<mailt