Bug 1494819 - Appliance doesn't start after upgrading from 5.7.4.0 to 5.8.2.0
Summary: Appliance doesn't start after upgrading from 5.7.4.0 to 5.8.2.0
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Appliance
Version: 5.7.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: GA
: 5.9.0
Assignee: Yuri Rudman
QA Contact: luke couzens
URL:
Whiteboard: black:upgrade:migration
Depends On:
Blocks: 1497817
TreeView+ depends on / blocked
 
Reported: 2017-09-23 12:03 UTC by Matouš Mojžíš
Modified: 2018-03-06 14:39 UTC (History)
8 users (show)

Fixed In Version: 5.9.0.1
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1497817 (view as bug list)
Environment:
Last Closed: 2018-03-06 14:39:13 UTC
Category: ---
Cloudforms Team: CFME Core
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
evm.log error (4.73 KB, text/plain)
2017-09-23 12:03 UTC, Matouš Mojžíš
no flags Details

Description Matouš Mojžíš 2017-09-23 12:03:37 UTC
Created attachment 1329905 [details]
evm.log error

Description of problem:


Version-Release number of selected component (if applicable):
5.7.4.0

How reproducible:
Always

Steps to Reproduce:
1. Have 5.7.4.0 appliance.
2. Stop appliance
3. Add cfme 5.8.2.0 repo
4. Upgrade appliance: yum upgrade cfme
5. bin/rake db:migrate
6. reboot appliance

Actual results:
Appliance doesn't start. evm.log added as attachment.

Expected results:


Additional info:

Comment 2 luke couzens 2017-09-25 10:43:25 UTC
Firstly, I have tested 5.7.3.2 to 5.8.2 the upgrade is successful with no seeding errors.

Secondly, I have tested 5.7.4 to 5.8.1.5 and see the same issue described in this bz. This tells me there is a problem with 5.7.4 itself.

Lastly, someone correct me if I am wrong but should we really be testing non-GA latest 5.7.z-stream to latest 5.8.z-stream, I mean in this specific case which build would be to blame and require a fix? As we are testing two potentially unstable releases.

Comment 4 Yuri Rudman 2017-09-28 12:47:01 UTC
Root cause of issue is the way we are seeding reports: if yaml file with report definition in /product directory is older than saved date for this report in DB than upgrade will be skipped.

after step 5 (in description to replicate issue) execute 
touch './product/reports/170_Configuration Management - Containers/050_Number of Nodes per CPU Cores.yaml'
and issue should go away

Comment 5 CFME Bot 2017-10-02 18:21:32 UTC
New commit detected on ManageIQ/manageiq/master:
https://github.com/ManageIQ/manageiq/commit/0b7e075ef6484ee491c3577ac4646bcec56a8219

commit 0b7e075ef6484ee491c3577ac4646bcec56a8219
Author:     Yuri Rudman <yrudman>
AuthorDate: Wed Sep 27 17:25:30 2017 -0400
Commit:     Yuri Rudman <yrudman>
CommitDate: Thu Sep 28 16:48:23 2017 -0400

    unconditionally seed all standard reports. Sometimes date of build for patch on new version could be older that build date of older version, and skipping file based on timestamp will lead to keeping records from old version
    https://bugzilla.redhat.com/show_bug.cgi?id=1494819

 app/models/miq_report/seeding.rb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Comment 6 CFME Bot 2017-10-02 18:21:37 UTC
New commit detected on ManageIQ/manageiq/master:
https://github.com/ManageIQ/manageiq/commit/ce79a8a2ca62c72820c5f38efd78f82ea644dd45

commit ce79a8a2ca62c72820c5f38efd78f82ea644dd45
Author:     Yuri Rudman <yrudman>
AuthorDate: Thu Sep 28 16:47:51 2017 -0400
Commit:     Yuri Rudman <yrudman>
CommitDate: Thu Sep 28 16:48:35 2017 -0400

    unconditionally seed widgets, skeeping seed based on file's timestamp may lead to keep recotrds from older version (when timestamp on yaml file from older version is more resent)
    https://bugzilla.redhat.com/show_bug.cgi?id=1494819

 app/models/miq_widget.rb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comment 8 luke couzens 2017-10-11 14:56:01 UTC
Verified in 5.9.0.2


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