Red Hat Bugzilla – Bug 1344112
Migration from 5.4 to 5.6.0.10 with replication fails
Last modified: 2016-06-29 12:07:14 EDT
https://github.com/ManageIQ/manageiq/pull/9177 will fix the region 99 case
https://github.com/ManageIQ/manageiq/pull/9178 will fix the region 0 case
New commit detected on ManageIQ/manageiq/master: https://github.com/ManageIQ/manageiq/commit/72784547cbe2d624162ddb82aa209c0b8b52432a commit 72784547cbe2d624162ddb82aa209c0b8b52432a Author: Nick Carboni <ncarboni@redhat.com> AuthorDate: Fri Jun 10 14:42:17 2016 -0400 Commit: Nick Carboni <ncarboni@redhat.com> CommitDate: Fri Jun 10 15:19:35 2016 -0400 Reset the column cache after adding default_miq_group_id to tenants Before this change, rails was not aware of the column if it was added in the same process that it was queried in. Specifically, the column cache is not reset after the `add_column` call; so for 20151021174140_assign_tenant_default_group.rb to work properly we need to reset the info manually via `Tenant.reset_column_information`. For example, the column would be added, but when we tried to set the value in 20151021174140_assign_tenant_default_group.rb we would silently fail or get a backtrace with: `99000000000001 is out of range for ActiveModel::Type::Integer with limit 4` After this change, the column value is set correctly. https://bugzilla.redhat.com/show_bug.cgi?id=1344112 db/migrate/20151021174044_add_tenant_default_group.rb | 3 +++ 1 file changed, 3 insertions(+)
New commit detected on ManageIQ/manageiq/master: https://github.com/ManageIQ/manageiq/commit/9debfda96e74eb1fea2e358cac294f04b5f01ed8 commit 9debfda96e74eb1fea2e358cac294f04b5f01ed8 Author: Nick Carboni <ncarboni@redhat.com> AuthorDate: Fri Jun 10 15:06:02 2016 -0400 Commit: Nick Carboni <ncarboni@redhat.com> CommitDate: Fri Jun 10 16:11:35 2016 -0400 Don't run a rake task from the host_storages migration This migration was created to fix some issues associated with adding and assigning a primary key when replication is enabled. `prepare_replication_without_sync` attempts to retrieve the replication worker settings; which as of #7432, requires the `settings_changes` table be present. This command will now fail because that table is added in a later migration. Removing this command will not cause an issue as rubyrep accounts for all unconfigured tables at first startup. We could also require running `rake evm:dbsync:prepare_replication_without_sync` after migration during upgrades. https://bugzilla.redhat.com/show_bug.cgi?id=1344112 db/migrate/20151208150956_fix_host_storage_replication_on_upgrade.rb | 2 -- .../20151208150956_fix_host_storage_replication_on_upgrade_spec.rb | 3 --- 2 files changed, 5 deletions(-)
Do changes need to be made to https://access.redhat.com/articles/2327481?
Nope, this was all fixed in the migrations
https://github.com/ManageIQ/manageiq/pull/9133
Verified in 5.6.0.11
https://github.com/ManageIQ/manageiq/pull/7620
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/RHBA-2016:1348