When using module level sharding, it will be good if we can mention the revision-date for the module in module-shard.conf. That will significantly help with model upgrading for production controllers. Hope that can be considered for Carbon.
On Fri, Mar 24, 2017 at 7:12 AM, Tom Pantelis <tompante...@gmail.com> wrote: > Since anything not tied to a specific shard goes into default, there could > be contention if multiple yang modules get hit with high volume. Using > specific shards alleviates that and also allows for more granularity wrt > shard-specifc settings like persistence and replication. Eg, you might want > one yang module to be replicated and another local-only. > > On Fri, Mar 24, 2017 at 10:04 AM, Srini Seetharaman < > srini.seethara...@gmail.com> wrote: > >> Thanks Muthu and Tom. So, for the case of my migration at this point, >> it feels like the easiest way is to retain the default sharding >> instead of defining my per-module sharding. Is there any performance >> downside to just using the default shard? >> >> On Fri, Mar 24, 2017 at 3:54 AM, Muthukumaran K >> <muthukumara...@ericsson.com> wrote: >> > Data import / export is a new feature in master branch which can export >> > datastore contents in JSON format and also import the same. Since this >> > feature is not there in earlier releases and would not be usable for >> moving >> > data from Be to Bo. >> > >> > >> > >> > Regards >> > >> > Muthu >> > >> > >> > >> > >> > >> > From: controller-dev-boun...@lists.opendaylight.org >> > [mailto:controller-dev-boun...@lists.opendaylight.org] On Behalf Of Tom >> > Pantelis >> > Sent: Friday, March 24, 2017 4:13 PM >> > To: Srini Seetharaman >> > Cc: controller-dev@lists.opendaylight.org >> > Subject: Re: [controller-dev] Backward compatibility of akka-persistence >> > journal >> > >> > >> > >> > There isn't any cluster-admin RPCs to defined new shards and migrate >> data. >> > You'd have to capture the data via REST from Beryllium and re-write it. >> > There is also a data import/export project but I'm not really familiar >> with >> > it. >> > >> > >> > >> > On Fri, Mar 24, 2017 at 1:06 AM, Srini Seetharaman >> > <srini.seethara...@gmail.com> wrote: >> > >> >> "instead of just relying on the default" - I assume you're referring to >> >> the default shard. All yang modules for which there isn't a shard >> specified >> >> in the .conf files are stored in the default shard. I suspect in your >> case >> >> the previous journal backup had the yang module in question stored in >> the >> >> default shard. However you had a specific shard defined in the .conf >> files >> >> so it went to that shard to read the data. The data in the default >> shard >> >> still exists and was restored but it just can't be accessed b/c >> reads/writes >> >> go to the specific shard. >> > >> > Totally explains what I'm going through. >> > >> > Is there a way to port data over from my older Beryllium controller >> > backup, which used the default shard, to my new Boron controller that >> > uses module-specific shards? Can I perform the restore first, and then >> > use the cluster-admin RPC to create the shards to move data over from >> > the default to the module-specific shard? >> > >> > >> > >
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
