Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: In situations such as pre- and post-receive hooks, presence of gems in a gear's $GEM_HOME can break /usr/bin/gear subcommands. For example, in a gear with activemodel-4.0.5 installed, this exception is raised by require 'openshift-origin-node/model/application_container': NameError: uninitialized constant ActiveModel::Observing from /opt/rh/ruby193/root/usr/share/gems/gems/openshift-origin-common-1.29.1/lib/openshift-origin-common/models/model.rb:13:in `<class:Model>' from /opt/rh/ruby193/root/usr/share/gems/gems/openshift-origin-common-1.29.1/lib/openshift-origin-common/models/model.rb:6:in `<module:OpenShift>' from /opt/rh/ruby193/root/usr/share/gems/gems/openshift-origin-common-1.29.1/lib/openshift-origin-common/models/model.rb:5:in `<top (required)>' from /opt/rh/ruby193/root/usr/share/rubygems/rubygems/custom_require.rb:55:in `require' from /opt/rh/ruby193/root/usr/share/rubygems/rubygems/custom_require.rb:55:in `require' from /opt/rh/ruby193/root/usr/share/gems/gems/openshift-origin-common-1.29.1/lib/openshift-origin-common.rb:22:in `<top (required)>' from /opt/rh/ruby193/root/usr/share/rubygems/rubygems/custom_require.rb:55:in `require' from /opt/rh/ruby193/root/usr/share/rubygems/rubygems/custom_require.rb:55:in `require' from /opt/rh/ruby193/root/usr/share/gems/gems/openshift-origin-node-1.34.1/lib/openshift-origin-node/model/frontend_proxy.rb:20:in `<top (required)>' from /opt/rh/ruby193/root/usr/share/rubygems/rubygems/custom_require.rb:55:in `require' from /opt/rh/ruby193/root/usr/share/rubygems/rubygems/custom_require.rb:55:in `require' from /opt/rh/ruby193/root/usr/share/gems/gems/openshift-origin-node-1.34.1/lib/openshift-origin-node/model/application_container.rb:18:in `<top (required)>' from /opt/rh/ruby193/root/usr/share/rubygems/rubygems/custom_require.rb:60:in `require' from /opt/rh/ruby193/root/usr/share/rubygems/rubygems/custom_require.rb:60:in `rescue in require' from /opt/rh/ruby193/root/usr/share/rubygems/rubygems/custom_require.rb:35:in `require' from (irb):11 from /opt/rh/ruby193/root/usr/bin/irb:12:in `<main>'irb(main):012:0> Version-Release number of selected component (if applicable): rubygem-openshift-origin-node-1.34.1-1.el6oso.noarch
For one user who experienced this issue, we have temporarily worked around it by changing his gear's git hooks to: GEM_HOME= gear prereceive and GEM_HOME= gear postreceive Unfortunately, this is not something a user can fix themselves.
Options: 1) Modify all git repositories' git hooks to unset GEM_HOME. This would require a migration. And it's not a complete solution (see below). 2) Modify the 'gear' script to add ENV['GEM_HOME']='' at the top, before the 'require' lines. Modify /usr/lib/openshift/cartridge_sdk/ruby/sdk.rb to do the same as well, because methods from this file are invoked as part of the build and deployment process from various cartridges from the 'control' script, which receives as its env the combination of the app, cart, and user env vars. #1 isn't a complete solution because it won't fix the calls made to /usr/lib/openshift/cartridge_sdk/ruby/sdk.rb. For #2, I haven't looked yet to see what the impact would be, if any, of modifying the ruby sdk.rb file. I think #2 is our best option, if we want to proceed, assuming it doesn't have adverse side effects.
PR: https://github.com/openshift/origin-server/pull/6065 Running extended gear and node tests now. Also creating a fork_ami for QE to test.
@agolste, I completely agree with you. I was not suggesting that my workaround was the right fix. That was just the easiest thing I could do without modifying things _outside_ the affected user's gear. And you are right that "gear deploy" and other commands are probably still failing for them; the user has not gotten back to me yet.
We have done the testing of the changes. Since the fork_ami build failed (online-broker cannot be started), I applied the changes to devenv_5410 to test it. After the changes are made, the installed conflicting gems via SSH into the gear will not block the non-scale git push, scaled apps git push and scale up. (Which can be reproduced w/o the fix) And we also do regression testing on this changes, there is no regression issue found.
PR is in the merge queue
The PR has been merged in to devenv_5424, and the issue was fixed. Move the bug to verified.