Several versions of a ruby gem can make conflict in automation engine


#1

In cloudforms 4.1, migrated from cloudforms 3.x:

For integration purpose, we had to add different versions of ruby gems which were still installed and used by the manageiq engine.

Example : we had to install ruby gem builder in version 2.1.2 since cloudforms 4.1 come with 3.2.2.

But it looks like gem versions are not specified in manageig engine:
./lib/charting/ziya_charting.rb: require ‘builder’
./lib/miq_automation_engine/engine/miq_ae_object.rb: require ‘builder’
./lib/miq_automation_engine/engine/miq_ae_workspace.rb: require ‘builder’
./lib/miq_automation_engine/models/miq_ae_class.rb: require ‘builder’
./lib/miq_automation_engine/models/miq_ae_field.rb: require ‘builder’
./lib/miq_automation_engine/models/miq_ae_instance.rb: require ‘builder’
./lib/miq_automation_engine/models/miq_ae_method.rb: require ‘builder’
./lib/miq_automation_engine/models/miq_ae_value.rb: require ‘builder’
./lib/resource_feeder/lib/resource_feeder/atom.rb: require ‘builder’
./lib/resource_feeder/lib/resource_feeder/rss.rb: require ‘builder’

Is there a way to specifiy version for manageiq engine?

Regards.


#2

ManageIQ dependencies are declared in the Gemfile, and as you can see there is no explicit dependency on builder. So changing it might be a bit tough.

As you are integrating with a quite complex product, I would advise working on dependencies the other way around: either update your integration code to use the new version of builder, or deploy builder in a different path and point to it in your require statement.

Personally, I prefer option #1, as you don’t have to manage an external gem tree, only for the sake of old dependencies. I have already faced this kind of issue and the update effort is most of the time quite minimal.

Can explain the difference of behavior between 2.1.2 and 3.2.2, and why you want to stick with 2.1.2 ?

Cheers,


#3

I can’t explain why there are 3 versions of builder (3.2.2, 3.0.4, 2.1.2) since the persons who installed them did not explained the purpose of and are not here anymore.

I would like to uninstall theses who are unused, though.

I have uninstalled 2.1.2 and things did not changed: ERRORS in logs.

I wanted to uninstall 3.0.4 too but there is a dependency - activemodel-3.2.17 - i don’t know what it is for.

We have several gems which have multiple versions:
actionpack (5.0.0, 1.13.6)
activemodel (5.0.0, 3.2.17)
activerecord (5.0.0, 1.15.6)
activesupport (5.0.0, 3.2.17, 1.4.4)
builder (3.2.2, 3.0.4)
fast_gettext (1.1.0, 1.0.0)
httpi (2.4.2, 2.0.2)
nori (2.6.0, 2.1.0)
rdoc (4.2.2, 4.2.0)
sass (3.4.22, 3.4.21)
wasabi (3.5.0, 3.1.0)

and we don’t know if we can uninstall older ones.

Regards.


#4

Looks quite entangled… Active* gems are heavily used by CloudForms, as they are linked to Ruby on Rails, and should be handled cautiously.

A strange thing is that you cannot have upgraded from 3.2 to 4.1. CloudForms 4.0, based on ManageIQ Darga, introduced RHEL 7 (resp. CentOS 7) as the underlying operating system, thus forcing a backup/restore procedure to do the migration. So the gem set on your appliance should be at worst the one from 4.0, mixed with 4.1.

I have check my CloudForms appliance, installed from 4.0 and updated to 4.1. Here is the version I have for the gems you mentioned:

  • actionpack (5.0.0)
  • activemodel (5.0.0)
  • activerecord (5.0.0)
  • activesupport (5.0.0)
  • builder (3.2.2)
  • fast_gettext (1.1.0)
  • httpi (2.0.2)
  • nori (2.1.0)
  • rdoc (4.2.2, 4.2.0)
  • sass (3.4.22, 3.4.21)
  • wasabi (3.1.0)

As you can see, some have multiple versions. I traced down the case of rdoc. Version 4.2.0 is installed by rubygem-rdoc package, which is a dependency of rubygems < ruby < cfme-gemset < cfme < cfme-appliance. So removing it is definitely not a good idea. I can’t judge if it is a bug or not. @chessbyte, any thought about that ?

By the way, I checked which version is loaded in CloudForms context and it is version 4.2.2, provided by package cfme-gemset:

$ vmdb
$ rails console
irb(main):001:0> gdep = Gem::Dependency.new('rdoc').matching_specs.max_by(&:version)
=> #<Gem::Specification:0x223da78 rdoc-4.2.2>

This behavior is enforced by the GEM_PATH environment variable that gives precedence to cfme-gemset gems:

$ env | grep GEMP_PATH
GEM_PATH=/opt/rh/cfme-gemset:/root/.gem/ruby:/opt/rh/rh-ruby22/root/usr/share/gems:/opt/rh/rh-ruby22/root/usr/local/share/gems

Can you rune the following command to identify the version CloudForms is using ?

$ vmdb
$ rails console << EOF
['actionpack', 'activemodel', 'activerecord', 'activesupport', 'builder', 'fast_gettext', 'httpi', 'nori', 'rdoc', 'sass', 'wasabi'].each { |g| puts Gem::Dependency.new(g).matching_specs.max_by(&:version).inspect }
EOF

I have the following output:

#<Gem::Specification:0x1f9d890 actionpack-5.0.0>
#<Gem::Specification:0x20d82a0 activemodel-5.0.0>
#<Gem::Specification:0x1fa0004 activerecord-5.0.0>
#<Gem::Specification:0x1f94da8 activesupport-5.0.0>
#<Gem::Specification:0x646734 builder-3.2.2>
#<Gem::Specification:0x1eacfe4 fast_gettext-1.1.0>
#<Gem::Specification:0x222ee60 httpi-2.0.2>
#<Gem::Specification:0x2226274 nori-2.1.0>
#<Gem::Specification:0x20c7a18 rdoc-4.2.2>
#<Gem::Specification:0x21366c0 sass-3.4.22>
#<Gem::Specification:0x2237970 wasabi-3.1.0>

If you have installed older versions of gems present in the CloudForms gemset, you’re stuck. I have tried to force the version of rdoc on the rails console and it fails due to the fact that the 4.2.2 version is already loaded by CloudForms:

$ vmdb
$ rails console
DEPRECATION WARNING: `config.serve_static_files` is deprecated and will be removed in Rails 5.1.
Please use `config.public_file_server.enabled = false` instead.
 (called from block in <top (required)> at /var/www/miq/vmdb/config/environments/production.rb:15)
Loading production environment (Rails 5.0.0)
irb(main):001:0> gem 'rdoc', '=4.2.0'
Gem::LoadError: can't activate rdoc (= 4.2.0), already activated rdoc-4.2.2. Make sure all dependencies are added to Gemfile.
	from /opt/rh/cfme-gemset/gems/bundler-1.12.5/lib/bundler/rubygems_integration.rb:332:in `block in replace_gem'
	from (irb):1
	from /opt/rh/cfme-gemset/gems/railties-5.0.0/lib/rails/commands/console.rb:65:in `start'
	from /opt/rh/cfme-gemset/gems/railties-5.0.0/lib/rails/commands/console_helper.rb:9:in `start'
	from /opt/rh/cfme-gemset/gems/railties-5.0.0/lib/rails/commands/commands_tasks.rb:78:in `console'
	from /opt/rh/cfme-gemset/gems/railties-5.0.0/lib/rails/commands/commands_tasks.rb:49:in `run_command!'
	from /opt/rh/cfme-gemset/gems/railties-5.0.0/lib/rails/commands.rb:18:in `<top (required)>'
	from bin/rails:4:in `require'
	from bin/rails:4:in `<main>'

Again, why not rewriting the automation code that relies on builder to use version 3.2.2 ?

Can you also provide the ERROR messages from logs ?


#5

You 're right, after verification, it is a migration from 4.0 to 4.1, sorry for the bad information.

rails console << EOF

[‘actionpack’, ‘activemodel’, ‘activerecord’, ‘activesupport’, ‘builder’, ‘fast_gettext’, ‘httpi’, ‘nori’, ‘rdoc’, ‘sass’, ‘wasabi’].each { |g| puts Gem::Dependency.new(g).matching_specs.max_by(&:version).inspect }
EOF
Loading production environment (Rails 5.0.0)
Switch to inspect mode.
[‘actionpack’, ‘activemodel’, ‘activerecord’, ‘activesupport’, ‘builder’, ‘fast_gettext’, ‘httpi’, ‘nori’, ‘rdoc’, ‘sass’, ‘wasabi’].each { |g| puts Gem::Dependency.new(g).matching_specs.max_by(&:version).inspect }
#<Gem::Specification:0x24e8a98 actionpack-5.0.0>
#<Gem::Specification:0x2628228 activemodel-5.0.0>
#<Gem::Specification:0x24f0f04 activerecord-5.0.0>
#<Gem::Specification:0x24e0bcc activesupport-5.0.0>
#<Gem::Specification:0x2653504 builder-3.2.2>
#<Gem::Specification:0x23fb450 fast_gettext-1.1.0>
#<Gem::Specification:0x277d790 httpi-2.0.2>
#<Gem::Specification:0x2776968 nori-2.1.0>
#<Gem::Specification:0x2615ba0 rdoc-4.2.2>
#<Gem::Specification:0x267ed08 sass-3.4.22>
#<Gem::Specification:0x2783758 wasabi-3.1.0>
[“actionpack”, “activemodel”, “activerecord”, “activesupport”, “builder”, “fast_gettext”, “httpi”, “nori”, “rdoc”, “sass”, “wasabi”]

I have finally uninstalled builder versions 3.0.4/2.1.2. Erro message in the logs disappeared, but we have still the problem: vsphere dot not set de ips on the guest (RH 6.7) .


#6

Good news. It doesn’t explain why you had old libraries, but at least it will be closer to the expected state.

About VMware setting the IP, you have created another thread : At what stage cloudforms set the vm Ips on vpshere and under what conditions?, on which I asked questions. If you don’t mind, I’d rather not mix the topics.


#7

Since it broke salt-api call and retirement in cloudforms, i installed again the 2 gems i uninstalled.