Necessary to keep old "gems" dirs within /opt/ood?

I’m curious if

  1. I’m doing something wrong when updating, such that the older gem rpms are being unnecessarily retained?
  2. 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?

[root@ondemand gems]# rpm -qa | grep ondemand | sort

[root@ondemand ood]# du -h --max-depth=3 /opt/ood/ondemand/root/usr/share/gems/ | grep -P 'ondemand/\d+'
289M    /opt/ood/ondemand/root/usr/share/gems/2.5/ondemand/1.8.12
292M    /opt/ood/ondemand/root/usr/share/gems/2.5/ondemand/1.8.18
284M    /opt/ood/ondemand/root/usr/share/gems/2.5/ondemand/1.8.20
293M    /opt/ood/ondemand/root/usr/share/gems/2.7/ondemand/2.0.13
321M    /opt/ood/ondemand/root/usr/share/gems/2.7/ondemand/2.0.16
332M    /opt/ood/ondemand/root/usr/share/gems/2.7/ondemand/2.0.18
179M    /opt/ood/ondemand/root/usr/share/gems/2.7/ondemand/2.0.23
334M    /opt/ood/ondemand/root/usr/share/gems/2.7/ondemand/2.0.20
137M    /opt/ood/ondemand/root/usr/share/gems/2.7/ondemand/2.0.28
137M    /opt/ood/ondemand/root/usr/share/gems/2.7/ondemand/2.0.29

The /opt/ood/ondemand/root/usr/share/gems subdir seems to take up 99% of the /opt/ood directory.

[root@ondemand share]# cd /opt/ood && /common/bin/showdirusage
File usage analysis: /opt/ood (and subdirectories)
  This directory's total size: 2.3G (2459401 KB)
Largest files/directories within /opt/ood:
  %/.  KBytes   IEC   Path
  99%  2459050  2.3G  /opt/ood/ondemand
  0%   192      188K  /opt/ood/ood-portal-generator

[root@ondemand ood]# cd /opt/ood/ondemand/root/usr/share && /common/bin/showdirusage
File usage analysis: /opt/ood/ondemand/root/usr/share (and subdirectories)
  This directory's total size: 2.3G (2452656 KB)
Largest files/directories within /opt/ood/ondemand/root/usr/share:
  %/.  KBytes   IEC   Path
  99%  2450917  2.3G  /opt/ood/ondemand/root/usr/share/gems
  0%   906      885K  /opt/ood/ondemand/root/usr/share/ruby

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.

1 Like

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.

I just “yum erased” all the older ondemand-gems on my dev server with no immediately visible ill effects.

I have no idea why the older gem packages stay around, but they do.

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.

Thanks for replying, everyone!

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.

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.