search

sonatype-nexus-community / nexus-repository-installer

Installer for Nexus Repository Manager 3
Apache License 2.0
32 stars 11 forks source link

Upgrade path to 3.71 broken due to missing 3.70 RPM build #40

Open ViliusS opened 1 month ago

ViliusS commented 1 month ago

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 commented 1 month ago

@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 commented 1 month ago

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 commented 4 weeks ago

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 commented 4 weeks ago

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.