Upgrade path to 3.71 broken due to missing 3.70 RPM build

[ViliusS]

According to https://help.sonatype.com/en/orient-pre-3-70-java-8-or-11.html one running 3.69 OSS needs to upgrade to 3.70 first before upgrading to 3.71. Unfortunately, 3.70 RPM was never built so now the upgrade path is broken.

[bhamail]

@ViliusS I'm still going through the hoops myself, but I'm pretty sure you can get past this without needing to upgrade to 3.70 first. The key issue is you need to migrate away from OrientDB to either H2 or PostreSQL, and that process is done using offline backups and a utility jar.

Unfortunately, I backed myself into a corner by NOT migrating my existing db away from Orient before upgrading to 3.71, and now I'm jumping through hoops to get my db migrated off of Orient. I'm pretty close to getting that working, but it is a very manual process, involving manual backup and restore, etc. (Not using native installers).

The main point I'm making is it is really important to migrate off of Orient DB and none of the installers in the community project can attempt to do that in an automated fashion. Having the installer "quietly" upgrade existing installs past 3.70 actually leaves you in a broken state because the database will still be on OrientDB.

[ViliusS]

I understand that the process is offline, but the main problem I see is that nexus-db-migrator-*.jars are available only from 3.70. In my opinion it should work this way:

1. RPM with 3.70 is released so that nexus-db-migrator tools is available to everyone running 3.69 RPM.
2. 3.71 RPM is taken offline and rereleased under different name, so nobody would botch they database by just doing yum update. Not to mention issues with yum downgrade.

What do you think?

[bhamail]

Interesting idea. I do think we need to make a smoother upgrade path, and it probably requires some sort of 3.70 installer, and maybe blocking behavior of moving from 3.70 to 3.71+ unless some conditions are true.

Ideally, I'd like the installer to be able to detect a prior installation, and "stop" if it can tell upgrading would put you into an invalid state. Of course, that will take some coding and effort to test. (I'm about to be away traveling, and can't foresee when I'll have cycles to dig into this effort, though I would welcome any help on it!).

I'm also scratching my head about if we should take the 3.71 rpm down. It is theoretically still useful for "new" installs, but could definitely bork existing "un-upgraded-old-db" installs.

[ViliusS]

I definitely think you should pull down 3.71 rpm and only then investigate how to do upgrade path properly. I myself was only saved by the fact that I'm using modified jetty-https.xml which got overwritten by the new RPM and Nexus server happily didn't start because of SSL keystore key mismatch.

If you could release 3.70 rpm before this weekend, I could go ahead to experiment how to actually block 3.71 install on invalid state. At least I think 3.71 could include Conflicts tag which would block installing over everything older than <= 3.69. Though I feel that just changing package name to something like sonatype-nexus-repository and informing about this in the README would be better. This would also make package name inline with the current branding name.

[bhamail]

@ViliusS I finally got some cycles to dig into this. Yikes! I agree, the v 3.71 installer is of little value (other than luckily it doesn't work due to being built with the wrong JVM - but if you are unfortunate enough to manually upgrade your JVM, you will next hit a wall if you have the OrientDB, which is likely for existing installations). I'll work on getting the 3.71 installer taken down.

That said, I don't think changing the package name will fly. I like the idea of a Conflict tag, and am curious to see if there's a way to "force" an upgrade when things conflict. That way we at least prevent people from getting wedged into an un-runnable state due to a non-upgraded database.

[bhamail]

OK, I had the v3.71 installer taken down.

I'm now trying to think through the safest way to implement a 3.70.1 installer. Given our latest published (working) installer is 3.69, I believe we need to follow these steps: https://help.sonatype.com/en/orient-pre-3-70-java-8-or-11.html (as you mentioned in your original report).

This boils down to a 3.70.1 installer with:

• jdk8
  This should be compatible with the 3.69 and prior installers.

Next I think we need a 3.71 installer with:

• jdk17

• check for OrientDB, e.g. nexus.orient.enabled=true in nexus.properties, and error out with doc links mentioned below.

• Conflicts tag with any version < 3.71 (as any such version could possible have an OrientDB database).

  Conflicts: nexus-repository-manager < 3.71.006-2
  

• verbose message that exits and points the user to docs to upgrade the database to H2. PostgreSQL requires a paid Nexus Repository Pro license, but that should work fine too.
  The database upgrade will be a manual process, so the installer should bail out with lot's of messages about why and what to do.

Future installers (3.71+) should include the same checks:

• check for OrientDB, e.g. nexus.orient.enabled=true in nexus.properties, and error out with doc links mentioned below.
• Conflicts tag with any version < 3.71 (as any such version could possible have an OrientDB database).
• verbose message that exits and points the user to docs to upgrade the database.

The one bright spot is brand new installs of 3.71 forward will get a shiny new H2 database and everything should "just work". It's only the existing upgrades from OrientDB that get tricky.