Gem bundle needs to be reinstalled for passenger app after upgrading from 1.6 to 1.7

Hello,

I just upgraded our OOD environment from 1.6 to 1.7. Overall, the upgrade was relatively quick and painless. The only thing I had trouble with was that one of my passenger apps stopped working. The error trace indicated that it was missing dependencies, so I assume this has to do with the Ruby 2.4 gems being incompatible with Ruby 2.5? The issue may be the same as the one described in this thread but I can’t quite tell.

In any case, reinstalling the gem bundle in the sandbox version of my app fixed the problem, so I just had to sync the new gems to the production app directory. However, I see in the release notes that we can now take advantage of a shared gem directory. Does this only apply to production apps, or sandbox apps as well? In particular, I’m wondering whether manually reinstalling bundles like I’ve done circumvents the shared gem location design, and if so, if there might be a more idiomatic way of updating passenger app dependencies?

Thanks,
Nick

Yes I believe the problem here is the switch from Ruby 2.4 to 2.5. You can have different passenger apps use different versions of Ruby, even different ones than the configured one for the PUN.

/opt/ood/nginx_stage/bin/ruby is the wrapper script for ruby that Passenger is configured to execute when starting a ruby rack app - see https://github.com/OSC/nginx_stage/blob/1bd909f1492c34137f6c6dc1b0e0f20a9c8f0f3a/bin/ruby

You can see by default it does exec ruby "$@" unless there exists an executable bin/ruby script in the application directory.

If you retain the older Ruby 2.4 software collection, then you can add a bin/ruby script with these contents:

#!/bin/bash

source scl_source enable rh-ruby24 rh-nodejs6

exec /bin/env ruby "$@"

That will use the SCLs from earlier and your app would continue to run after the upgrade.

Funny thing, is we actually have some custom passenger apps still using Ruby 2.4 at OSC. I just noticed one of our older shared apps that broke when we upgraded, I quickly added this to fix it and then forgot about it.

As for the shared gem directories, that applies to all apps. Of course, if you are using bundler, and you do a bundle install --path vendor/bundle it will install all the dependencies to a local directory, and then you will not be using the system installed gems (the shared directories). So it only is beneficial if you can get by without using gems other than the system installed gems or your app is built into an rpm that takes advantage of these shared gems. @tdockendorf would be better to explain how that actually works if you are curious.

I don’t know yet how to best guide users to using these gemsets. One of the ideas was your apps could depend on a particular gem set version (such as ondemand-gems-1.7.10-1.7.10-2.el7.x86_64.rpm) and so as long as that rpm was installed those apps would run without having to run bundle install to install local copies of the gems. Which means for simple apps that don’t need gems besides what is in that rpm, you can just deploy the code and run it. Rails apps would still require building assets for production, however.

What isn’t clear to me yet is what guidance should be given to developers who want to build an app utilizing these system gems, combined with some extra gems their particular app needs, and still get by without having to create an rpm for their app.

I think that manually reinstalling bundles like you do is fine though. Since in development we are often making changes to the Gemfiles of the core apps of OnDemand, we often don’t build against the system gems either, and end up regularly installing a separate copy of the gems.

1 Like

The shared gems works if you do scl enable ondemand -- bundle install from your app. That will put the gems into the shared path that is versioned so with ondemand-gems-1.7.10 they’d get installed to a path with that version in path so they stay around until you uninstall the ondemand-gems-1.7.10 RPM which won’t happen automatically with upgrades. If you choose not to install gems this way that’s fine too but won’t break anything. The one thing we stopped supporting was a home directory ~/.bundle/config which is normally defined by BUNDLE_USER_CONFIG environment variable. We had to disallow that to ensure user’s global bundler config didn’t break OnDemand apps and prevent people from loading whatever gems they want regardless of what admins defined as appropriate for an app.