New commit detected on ManageIQ/manageiq-schema/gaprindashvili: https://github.com/ManageIQ/manageiq-schema/commit/73f1f7633ae4ffa726c1fceec92c42465500429a commit 73f1f7633ae4ffa726c1fceec92c42465500429a Author: Jason Frey <fryguy9> AuthorDate: Fri Mar 16 12:04:36 2018 -0400 Commit: Jason Frey <fryguy9> CommitDate: Fri Mar 16 12:04:36 2018 -0400 Merge pull request #179 from carbonin/sort_tables_before_removing_limits Remove the limits from the tables in sorted order (cherry picked from commit 565c01f3b9282952bb4e6d38316222dbed5ee77f) Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1558626 db/migrate/20171109225052_remove_string_column_limits.rb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
So I tested this against a fresh 5.6 appliance and migration was successful so I would guess there is another issue with the customer db backup.
Jason, can you take a look at this? It looks like the TimeProfile.default method in the migration is returning nil - https://github.com/gtanzillo/manageiq-schema/blob/4e927e1e1263320480c26b48d2f667232b2b0aaa/db/migrate/20170207215322_fix_vpor_time_profile_ids.rb#L40 Seems like that should never happen if there are actually VimPerformanceOperatingRange instances in the DB
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2018:1328