Bug 1314737

Summary: 5.4 DB migration to 5.5 appliance fail
Product: Red Hat CloudForms Management Engine Reporter: luke couzens <lcouzens>
Component: ApplianceAssignee: Nick Carboni <ncarboni>
Status: CLOSED NOTABUG QA Contact: luke couzens <lcouzens>
Severity: high Docs Contact:
Priority: unspecified    
Version: 5.5.0CC: abellott, jhardy, lcouzens, nachandr, ncarboni, obarenbo
Target Milestone: GA   
Target Release: 5.6.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: migration
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-04-13 13:02:16 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Comment 3 Nick Carboni 2016-03-04 21:58:03 UTC
Ah pulled the host from the pastebin.

I forgot you can't reproduce these locally. Even though it looks like you're getting the same error you are actually failing because you don't have the customer's replication configured.

On that test machine I'm getting:
Exception caught: Replication configuration missing
/var/www/miq/vmdb/lib/miq_rubyrep.rb:18:in `prepare_configuration'

With the edits I made to the migration you will be able to see exactly why the underlying command is failing.

Specifically this is what I added in /var/www/miq/vmdb/db/migrate/20131216214850_fix_replication_on_upgrade_from_version_four.rb

      say_with_time("Preparing rubyrep") do
        begin
          AwesomeSpawn.run!("bin/rake evm:db:environmentlegacykey evm:dbsync:prepare_replication_without_sync")
        rescue AwesomeSpawn::CommandResultError => e
          res = e.result
          puts "result command line: #{res.command_line}"
          puts "result stdout: #{res.output}"
          puts "result stderr: #{res.error}"
          puts "result exit status: #{res.exit_status}"
          raise
        end
      end

So I would need for that edit to be made and then the migration to be run again on the customer's environment.  That should give us some better information.

Comment 4 Nick Carboni 2016-04-13 13:02:16 UTC
This was caused by trying to migrate a customer database with existing replication settings when the target host would not be reachable.