Hi Srini, Actually changing revision-date of the recommended practices of RFC 6020 in general - https://tools.ietf.org/html/rfc6020#section-10
But, could you please elaborate how referring revision in module-shards.conf will be useful in upgradeability context ? I have noticed that models are changed *without* bumping the revision dates. As I could think, one main reason for inhibition on changing revision-date religiously across model-changes is that binding classes generated from yang models include the revision in the package name – eg. *.revABCD.*. If revision-date gets changed at model level, generated packages also will change and subsequently all modules who use the generated binding classes for the corresponding yang-model would have change their imports. Regards Muthu From: srini...@gmail.com [mailto:srini...@gmail.com] On Behalf Of Srini Seetharaman Sent: Wednesday, March 29, 2017 7:31 AM To: Tom Pantelis Cc: Muthukumaran K; controller-dev@lists.opendaylight.org Subject: Re: [controller-dev] Backward compatibility of akka-persistence journal 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<mailto: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<mailto: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<mailto: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> > [mailto: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<mailto: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<mailto: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
