Migrate from old ivanchuk-4 to quinteros

[ivocarvalho]

Hello.

I have a manageiq appliance on ivanchuk-4 and since CentOS 7 has reached EOL upgrading has become a challenge.

I've been trying to follow the guide here - https://github.com/orgs/ManageIQ/discussions/22745 - but keep getting errors when doing the db migrate.

So I was wondering if it would be easier, or possible, to download the newest appliance (quinteros) and restore it with a pg_dump done on the older one or even using the appliance_console to backup and restore?

[Fryguy]

@jrafanie Can you help out here?

[jrafanie]

@ivocarvalho It's often easier to do a pg_dump from the old version and pg_restore on the new one using similar steps as described in the link. Keep your original appliances around so you can copy over any files such as your /var/www/miq/vmdb/certs/v2_key (encryption key) and apache certificates if you created them.

Going from ivanchuk to quinteros is jumping 8 releases and going from ruby 2.5 with rails 5.1 and postgres 10 to ruby 3.0 with rails 6.1 and likely postgres 13. Because of the postgres 13 change, you'll need to dump/restore anyway. See my comments in the discussion you linked to.

If you have custom ruby automation scripts and you skip version upgrades, you'll likely skip over deprecations and have APIs completely removed, possibly breaking your ruby automations, so it might be worthwhile following an upgrade path so you are skipping no more than 1 ruby or 1 rails version.

For example, I think this path skips as many manageiq versions without upgrading more than 1 ruby or 1 rails version. 2 ruby or 2 rails upgrades means you miss the chance to detect deprecations or API removals. Keep in mind, manageiq code changes between versions also, so it's possible we deprecate, change or remove an API if you skip more than 1 version.

ivanchuk  => kasparov  (ruby 2.5 to 2.6 and rails 5.1 to 5.2)
kasparov  => najdorf   (ruby 2.6 to 2.7 and rails 5.2 to 6.0)
najdorf   => quinteros (ruby 2.7 to 3.0 and rails 6.0 to 6.1) *
quinteros => radjabov  (ruby 3.0 to 3.1 and rails 6.1 to 7.0) **

* Oparin, petrosian and quinteros started the upgrade of postgres from 10 to 13. This will require pg_dump from 10 and pg_restore in 13. You can't take a postgres 10 database from the filesystem and run it with postgres 13. It might also cause schema migration or column issues later on but I think ruby automations are principally affected by rails upgrades and secondarily by ruby upgrades.

** radjabov (NOT YET RELEASED) will also upgrade the OS from el8 to el9 so it's a requirement to dump/restore.

If you run into issues and want to provide sanitized log snippets, we might be able to guide you.

Best of luck!

EDIT: Clarified radjabov unreleased status and made it clear when dump/restore is required.

[Fryguy]

Note that, as of this comment, radjabov isn't out yet, sothe quinteros => radjabov bit is only if you're upgrading to something like a nightly build. When radajbov releases though, that el8 to el9 statement still holds.

[jrafanie]

Thanks, I updated the comment with your suggestion.