Bug 1411890 - upgrade from 4.1 to 4.2 works, but web-ui still shows repository from 4.1
Summary: upgrade from 4.1 to 4.2 works, but web-ui still shows repository from 4.1
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Appliance
Version: 5.7.0
Hardware: x86_64
OS: Linux
Target Milestone: GA
: cfme-future
Assignee: Gregg Tanzillo
QA Contact: luke couzens
Whiteboard: upgrade
Depends On:
TreeView+ depends on / blocked
Reported: 2017-01-10 16:52 UTC by Reartes Guillermo
Modified: 2018-08-14 21:14 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2018-08-14 21:14:53 UTC
Category: ---
Cloudforms Team: ---
Target Upstream Version:

Attachments (Terms of Use)
web-ui showing old repo (117.67 KB, image/png)
2017-01-10 16:53 UTC, Reartes Guillermo
no flags Details
web-ui showing old repo (after refresh) (83.78 KB, image/png)
2017-01-10 16:55 UTC, Reartes Guillermo
no flags Details
appliance_console after upgrade (29.05 KB, image/png)
2017-01-10 16:55 UTC, Reartes Guillermo
no flags Details

Description Reartes Guillermo 2017-01-10 16:52:43 UTC
Description of problem:

Updated a fresh CloudForms 4.1 to 4.2 upgrade.
The appliance was an all-in-one poc setup.
The appliance is registered to a atellite 6.2 instance.

The upgrade process finished ok, but noticed that in the web-ui the old repository is still shown and the cfme version is shown in red color.

Version-Release number of selected component (if applicable):
Upgrade from CFME to

How reproducible:
provably always (1 did the upgrade process only one)

Steps to Reproduce:
1. install cloudforms 4.1 (single appliance, all in one)

2. perform the upgrade process:
   URL: https://access.redhat.com/documentation/en/red-hat-cloudforms/4.2/single/migrating-to-red-hat-cloudforms-42/

3. check that all is ok
4. reboot the appliance from appliance_console
5. check yum repolist, ok
6. check appliance_console, ok
7. via web-ui, go to adminstrator -> configuration -> region -> red hat updates
   the field "repository name(s)" does show the OLD repo for CloudForms 4.1

Actual results:
wrong value for field "repository name(s)"

Expected results:
the field "repository name(s)" should display the repos for CloudForms 4.2

Additional info:

# yum repolist
Loaded plugins: product-id, search-disabled-repos, subscription-manager
repo id                                  repo name                                                               status
!cf-me-5.7-for-rhel-7-rpms/x86_64        Red Hat CloudForms Management Engine 5.7 (RPMs)                             57
!rhel-7-server-rpms/7Server/x86_64       Red Hat Enterprise Linux 7 Server (RPMs)                                13,602
!rhel-server-rhscl-7-rpms/7Server/x86_64 Red Hat Software Collections RPMs for Red Hat Enterprise Linux 7 Server  7,118
repolist: 20,777

Comment 2 Reartes Guillermo 2017-01-10 16:53:46 UTC
Created attachment 1239156 [details]
web-ui showing old repo

Comment 3 Reartes Guillermo 2017-01-10 16:55:03 UTC
Created attachment 1239159 [details]
web-ui showing old repo (after refresh)

Comment 4 Reartes Guillermo 2017-01-10 16:55:36 UTC
Created attachment 1239161 [details]
appliance_console after upgrade

Comment 5 Nick Carboni 2017-01-30 22:02:30 UTC
This seems to have been caused by this change (https://github.com/ManageIQ/manageiq/pull/11304/files#diff-83db7da7e7e6f4bcc58fc9e6b6637e9aR14).

What's happening here is when we moved the value out of the database so we could get it out of the upstream code, we took whatever was there and put it in as a new user provided value.

This value won't be overwritten by our new default value even if it was the default to begin with.

A workaround for this would be to change the repos to the new default by editing the registration and clicking the "Default" button for the "Repository Name(s)" input box.

In the database, this will remove the settings_changes row and take the default from now on when it is updated by new rpm versions.

As to how to fix this, I'm not sure. Should we create a new migration to remove the settings change row if it was a previous version's default?

Comment 6 Yuri Rudman 2018-08-14 21:14:53 UTC
Closing this BZ since there are no activity for the last 1.5 years and version 5.7 in "Maintanace Support" phase.

Note You need to log in before you can comment on or make changes to this bug.