Best way to upgrade from Ivanchuk to Kasparov

Dear alll,

To use newer version of MIQ, I usually run a new appliance and import my old DB onto this newer version like :

  • export the old data from the old PG
  • copying the keys / guid / etc to the new appliance
  • import the data into the new PG
  • rake db:migrate on the new PG
  • rake evm:automate:reset on the new PG

This worked (nearly ) like a charm until Kasparov version.

I used a Invachuk-1 version and wanted to import to a Kasparov-1 version.

Using the same process, every start well until the login : I’ve had an error like “undefined method `positive?’ for nil:NilClass”.

After commenting directly some source code ( :sweat_smile: ), I managed to log in but went :

Capture d’écran du 2021-05-27 14-31-29

Before going forward, is there a proper way to upgrade from an Ivanchuk 1 appliance to a Kasparov ?

Regards !

For example, i had to comment this in app/models/user.rb in the locked? func :

::Settings.authentication.max_failed_login_attempts.positive? && failed_login_attempts >= ::Settings.authentication.max_failed_login_attempts

I’ve replace it by false and manage to login.

I have the same issue with a Jansa-3 version.

Is there a tool/script to check/reload the db schema ?


You can try launching rails console:

cd /var/www/miq/vmdb
bin/rails console

puts User.find_by(:userid => "YOUR_USERNAME").failed_login_attempts
puts ::Settings.authentication.max_failed_login_attempts

You can always set the max_failed_login_attempts without the UI with something like this from the vmdb directory:

% ./tools/configure_server_settings.rb --type=integer --serverid=1 --path=authentication/max_failed_login_attempts --dry-run --value "3"
{:dry_run=>true, :serverid=>1, :path=>"authentication/max_failed_login_attempts", :value=>"3", :force=>false, :type=>"integer", :all_servers=>false, :help=>false, :type_given=>true, :serverid_given=>true, :path_given=>true, :dry_run_given=>true, :value_given=>true}
** ManageIQ master, codename: Morphy
Setting [authentication/max_failed_login_attempts], old value: [3], new value: [3]
Dry run, no updates to server 1 have been made

Note, that command was run from master but it should work on kasparov. It also doesn’t do anything. Remove the dry run and configure the serverid for your server from rails console.

Based on your user’s failed login attempts and your current max_failed_login_attempts, it’s possible the upgrade wasn’t done completely, so report back any results.

Thanks a lot !

I’ve finishied to compare settings between a fresh Kasparaov and my Ivanchuk and find some of the settings missing.

My first task to do today was to find the correct way to add missing settings with configure_server_settings.rb.

Thanks for your reply ! I’ll keep you in touch.


You should only need to worry about things you’ve changed as we’ll always use the default settings.yml for each release as the baseline with only your changes on top.

We store the changes you’ve made to the configuration in the settings_changes table. Primarily, you’re more interested in the rows for your, which are in the ones with the same id value in the resource_id column. What you see in the advanced settings is the aggregate of “defaults”, server settings, zone settings, etc. By looking at things like MiqServer.my_server.settings_changes.pluck(:key, :value) in rails console or the same for your Zone, you can see what specific things you’ve changed.

I now have the login ok after adding the missing setting.

Now, some other missing settings cause the dahsboard ( and others pages ) to crash.

In the production.log, I have now the following error :

[----] F, [2021-06-01T11:56:39.772019 #12258:2ac51c73308c] FATAL -- : Error caught: [ActionView::Template::Error] undefined method `product_documentation_direct_link' for nil:NilClass
[----] F, [2021-06-01T11:56:39.800465 #12258:2ac51c73308c] FATAL -- : ActionView::Template::Error (undefined method `product_documentation_direct_link' for nil:NilClass):

Unfortunatly, I couldn’t set this settings like the authentication.max_failed_login_attempts

In the rails console:

irb(main):001:0> puts
Traceback (most recent call last):
       12: from bin/rails:4:in `<main>'
       11: from bin/rails:4:in `require'
       10: from railties ( lib/rails/commands.rb:18:in `<top (required)>'
        9: from railties ( lib/rails/command.rb:46:in `invoke'
        8: from railties ( lib/rails/command/base.rb:69:in `perform'
        7: from thor (1.0.1) lib/thor.rb:392:in `dispatch'
        6: from thor (1.0.1) lib/thor/invocation.rb:127:in `invoke_command'
        5: from thor (1.0.1) lib/thor/command.rb:27:in `run'
        4: from railties ( lib/rails/commands/console/console_command.rb:96:in `perform'
        3: from railties ( lib/rails/commands/console/console_command.rb:19:in `start'
        2: from railties ( lib/rails/commands/console/console_command.rb:64:in `start'
        1: from (irb):1
NoMethodError (undefined method `product_documentation_direct_link' for nil:NilClass)
=> nil
irb(main):005:0> puts

=> nil

In my Ivanchuk, in custom settings section :


In the clean Kasparov :

  :product_documentation_direct_link: true

However , in the Ui sources, in the app/presenters/menu/default_menu.rb, I can see this :

      def help_documentation
        # note these can still be overriden via Settings.help_menu
        href = if
        help_menu_item(:documentation, :title => N_('Documentation'),
                                       :href  => href)

      def help_product
        help_menu_item(:product, :title =>,
                                 :href  =>

I’m surely missing some point here.
I’ve tried to set the product_documentation_* and the product_support_* settings in the help_menu, but same result.

Do you have any ideas ?

Strange, on my Invachuk, I have the docs settings via the console :

irb(main):001:0> puts
#<Config::Options ansible_provider="", cloud_provider="", configuration_provider="", container_provider="", infra_provider="", network_provider="", physical_infra_provider="">
=> nil

I’m confused. Do you have local changes to config/settings.yml?. It’s a checked in file and should not be modified locally. Therefore, when downloading a kasparov-1 based appliance, it will have the code at that version, which contains the product_documentation_direct_link and related changes here.

All changes you make should be done through either the UI in the various configuration tabs, advanced settings, or through the configure_server_settings script I shared previously.


I just see in my restore playbook that I copy the settings.yml …

My bad !

I skip this step and test again.

Thanks a lot ! I’ll keep you in touch.

Great. Would you be able to share your process after fixing the playbook? The settings.yml overwrite really made your upgrade steps harder and I’m glad you got to the bottom of it. It shouldn’t be that many steps to upgrade so please do share so maybe we can simplify some of the steps.