HELP Upgrading to 6.0.1 - Module Baselines not migrated successfully
In our repotools-rm_addTables log, we see that 740 baselines are found.
Shortly later, we see:
"Retrieving baseline metadata..."
Followed by:
"Migration FAILED"
and:
"Error running migration"
java.lang.NullPointerException: null key in entry: null = com.ibm.rdm.repotools.commands.upgrade.migration.UpgradeToLocalVersioning$MBLMeta@6d68272b
After that, we do not see any reports of module baselines being migrated successfully.
The upgrade script proceeded, and is now re-baselining. We are hoping to get this figured out and proceed with the upgrade, but need to know quickly before we hit our deadline for rolling back.
Shortly later, we see:
"Retrieving baseline metadata..."
Followed by:
"Migration FAILED"
and:
"Error running migration"
java.lang.NullPointerException: null key in entry: null = com.ibm.rdm.repotools.commands.upgrade.migration.UpgradeToLocalVersioning$MBLMeta@6d68272b
After that, we do not see any reports of module baselines being migrated successfully.
The upgrade script proceeded, and is now re-baselining. We are hoping to get this figured out and proceed with the upgrade, but need to know quickly before we hit our deadline for rolling back.
Comments
Nate Decker
Jan 23 '16, 2:45 p.m.In researching this problem, I've noticed that other users had issues at this same stage of the update due to anomalies in their module baselines. For example, I found some examples of a "GoneException" when a module baseline is created and then the module is deleted. Linked to the Defect tracking this issue, there was another example when a Module baseline has a blank title. In our environment we have 740 module baselines so there is ample opportunity for an anomalous example. In particular, we had a previous service request for a module baseline that was never created correctly. In that case, the module baseline was corrupt and couldn't even be opened or viewed. At the time we were given steps for deleting the module baseline, but the users elected to leave the baseline rather than risk changing something in the database. It seems entirely possible that this may be a possible cause. It seems that IBM's migration code is not very robust or fault-tolerant.