| Summary: | 5.4 DB migration to 5.5 appliance fail | ||
|---|---|---|---|
| Product: | Red Hat CloudForms Management Engine | Reporter: | luke couzens <lcouzens> |
| Component: | Appliance | Assignee: | Nick Carboni <ncarboni> |
| Status: | CLOSED NOTABUG | QA Contact: | luke couzens <lcouzens> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 5.5.0 | CC: | 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: | |
This was caused by trying to migrate a customer database with existing replication settings when the target host would not be reachable. |
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.