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 <guy.s...@hpe.com>; Tom Pantelis <tompante...@gmail.com> Cc: odl netvirt dev <netvirt-...@lists.opendaylight.org>; controller-dev@lists.opendaylight.org; integration-...@lists.opendaylight.org; Kochba, Alon <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 <muthukumara...@ericsson.com<mailto:muthukumara...@ericsson.com>>; Tom Pantelis <tompante...@gmail.com<mailto:tompante...@gmail.com>> Cc: odl netvirt dev <netvirt-...@lists.opendaylight.org<mailto:netvirt-...@lists.opendaylight.org>>; Kochba, Alon <alo...@hpe.com<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 <guy.s...@hpe.com<mailto:guy.s...@hpe.com>>; Tom Pantelis <tompante...@gmail.com<mailto:tompante...@gmail.com>> Cc: odl netvirt dev <netvirt-...@lists.opendaylight.org<mailto:netvirt-...@lists.opendaylight.org>>; Kochba, Alon <alo...@hpe.com<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 <tompante...@gmail.com<mailto:tompante...@gmail.com>> Cc: odl netvirt dev <netvirt-...@lists.opendaylight.org<mailto:netvirt-...@lists.opendaylight.org>>; Kochba, Alon <alo...@hpe.com<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 <guy.s...@hpe.com<mailto:guy.s...@hpe.com>> Cc: Robert Varga <n...@hq.sk<mailto:n...@hq.sk>>; Kochba, Alon <alo...@hpe.com<mailto:alo...@hpe.com>>; Williams, Marcus <marcus.willi...@intel.com<mailto:marcus.willi...@intel.com>>; Daniel Farrell <dfarr...@redhat.com<mailto:dfarr...@redhat.com>>; odl netvirt dev <netvirt-...@lists.opendaylight.org<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 <guy.s...@hpe.com<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 <guy.s...@hpe.com<mailto:guy.s...@hpe.com>>; Tom Pantelis <tompante...@gmail.com<mailto:tompante...@gmail.com>>; Kochba, Alon <alo...@hpe.com<mailto:alo...@hpe.com>> Cc: Williams, Marcus <marcus.willi...@intel.com<mailto:marcus.willi...@intel.com>>; Daniel Farrell <dfarr...@redhat.com<mailto:dfarr...@redhat.com>>; odl netvirt dev <netvirt-...@lists.opendaylight.org<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 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
