Hi Muthu Let's say I update the revision of a module XYZ from t1 to t2, then I noticed that MD-SAL allows keeping both data in the store but separated by revision-date. This allows me to port over data from module-t1 to module-t2. I need it in the t2 rev because new apps might use the new revision classes, while backed up data/wiring might be of revision t1.
I can see cases where it is possible to store module-t2 data in one or more shards that are different from the shard where module-t1 is store. In such cases, allowing the sharding to include revision-date along with the module/namespace makes sense. Srini. On Wed, Mar 29, 2017 at 10:09 PM, Muthukumaran K < muthukumara...@ericsson.com> wrote: > 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> > 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
