Recommended upgrade and migration path from Petrosian (16) to Radjabov (18) #23690
Replies: 3 comments 14 replies
-
In terms of tested/supported, yes, that's basically it. If you run into issues it will be in c extension gems that depend on OS packages. If we upgraded a c extension gem that depends on OS packages, like qpid-proton or pg, you risk not being able to install them. Also, things like the black console configuration page may run functions that may not be compatible with centos8 versions of packages. So as soon as you try to run radjabov code on centos 8, you could have issues if the correct dependencies aren't installed. You can see some of the changes we did to get to el9 but keep in mind there could have been other changes we did afterwards: ManageIQ/manageiq-appliance-build#515
Keep in mind, you'll need to transfer encryption keys (v2_key, or you won't be able to decrypt your encrypted passwords) and GUID (if you want the new server to take the place of the original one including all of it's settings). Personally, I prefer the OS-first approach. In a test environment, install a new centos 9 petrosian, perform the db dump/restore, transfer the v2_key and GUID from the original server, migrate the database, reset the ae datastore to petrosian, configure it properly, and verify the installation including any automations. Keep in mind, check the ruby and rails versions before and after. I suspect you're going from ruby 3.0 and rails 6.1 to ruby 3.1 and rails 7.0. If you run into any problems you can certainly review this list and see if you have your own customizations that need similar fixes: |
Beta Was this translation helpful? Give feedback.
-
|
I am currently blocked : 1. Petrosian installation on COS 9
2. Upgrade from Petrosian (on my actual COS 8 instance ) to Quinteros
3. Systemd service behavior
4. Steps already attempted
At this point, both installing Petrosian on COS 9 and upgrading Petrosian to Radjabov on COS 8 are blocked due to gem/load path issues with ActiveSupport and Bootsnap. Any guidance on resolving these dependency/load path issues or alternate upgrade/install procedures would be greatly appreciated. Thanks, Jonathan |
Beta Was this translation helpful? Give feedback.
-
|
I followed your previous instructions as closely as possible. Below is a summary of what I’ve done and the issue I’m currently facing. What I did
Current status
When checking the Apache logs, I see repeated proxy errors indicating connection refusals on ports 3000–3009, for example: This makes it look like Puma is not running properly, or at least not listening on the expected 300* ports. Additional tests I tried starting the Rails server manually with:
In this case, the UI is reachable and works as expected. Question Did I miss something related to Puma configuration or initialization? As far as I remember, I never had to manually touch Puma on my previous appliance. One additional detail that may or may not be relevant: to align with our internal standards, I moved /var/www/miq to /opt/apps/miq and set up a bind mount so that /var/www/miq still exists and points to the new location. Could this be related to the issue? Thanks in advance for your help. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hello ManageIQ community,
I’m looking for guidance on the recommended upgrade and migration strategy for ManageIQ.
Current setup
Target
Options considered so far
At this stage, I currently see two possible options:
I would appreciate feedback on whether either of these approaches is recommended, supported, or strongly discouraged.
Regards,
Beta Was this translation helpful? Give feedback.
All reactions