I’m doing something wrong when updating, such that the older gem rpms are being unnecessarily retained?
Is it ok to clear out the old stuff? (gems rpms, and /opt/ood/…/gems dirs)
This seems closely related to a previous post, but that really only seems to imply it’s safe to remove 1.x versions after moving to 2.x: Is it safe to erase old ondemand-gem RPMs?
Yes it should be safe to remove them provided you don’t have other Ruby Passenger applications that depend on them. If you don’t know what that means, then you don’t have other Ruby Passenger apps.
Looks like you can delete everything less than ondemand-gems-2.0.28-2.0.28-1.el8.x86_64, Though I would start with the oldest (ondemand-gems-1.8.12-1.8.12-1.el8.x86_64) and test 1 at a time. That is, remove the oldest and verify you’re all good by restarting your web server. If it all comes back up then you can move on to the next.
I’m about 90% sure it’s safe for you to delete up to and including ondemand-gems-2.0.28-2.0.28-1.el8.x86_64 if you’re running OnDemand 2.0.29, but would ask @tdockendorf to confirm to put me at 100.
That said - even if you can delete up to ondemand-gems-2.0.28-2.0.28-1.el8.x86_64 I’d wait for an opportune time to do so.
It could be the case that your users have pulled some of those files into memory and if you delete them from under them - i.e., they hit a certain code path and expect the file to be there - there could be errors even though that file is somewhere else.
I’m not sure what the behavior is in this case or if older gems are loaded first in the library path. So while I believe it’s safe in the long run, it may not be safe in that moment when some PUNs have loaded those gems and expect them to be there and you’ve removed them from the file system after they’ve loaded them (or at least their paths) into memory.
For OSC what I’ve done as we’ve moved from OnDemand 1.8 to 2.0 and now 2.1 I will wait for all apps to get rebuild that rely on gems and then do something like this:
yum remove ondemand-gems-1.8\*
If you run OnDemand 2.0.29 you can delete up to and including ondemand-gems-2.0.28 provided you don’t have apps using the older gems.
The old packages stay around to avoid breaking Ruby apps immediately when OnDemand gets upgraded that might have gems with different versions or that simply no longer exist in the RPM.
Ok, so I read loud and clear that the old packages
might be needed by ood apps that haven’t been updated in some time, and
that a sure-fire way to know is to iteratively remove the old gem packages and check to make sure apps are still standing
and that one would want to do that removal process during downtime, and starting from oldest first, but not to include the current instance version
…so I’ve got everything I need. Thank you!
Bonus question for the benefit of those not super familiar with ruby and/or gems – is there a straightforward way (in lieu of an app’s documentation) to know if App X has old dependencies?
The only way I can think would be to just check the ‘Gemfile’ itself and see what the dependencies are for the app. The ‘Gemfile.lock’ can provide the exact version of the dependency if it isn’t in the ‘Gemfile’.
You’d then just need to ensure the dependency is still satisfied with what is in the newer versions gems. Be sure to check the version numbers though, because it may be the dependency is there but it’s a newer version which may break the app using the old version.