Bug 1368192 - error when seeding TimeProfile post upgrade from 4.0 to 4.1
Summary: error when seeding TimeProfile post upgrade from 4.0 to 4.1
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Appliance
Version: 5.6.0
Hardware: All
OS: All
high
high
Target Milestone: GA
: 5.7.0
Assignee: Nick Carboni
QA Contact: Jan Krocil
URL:
Whiteboard: upgrade
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-08-18 15:39 UTC by Felix Dewaleyne
Modified: 2021-06-10 11:28 UTC (History)
6 users (show)

Fixed In Version: 5.7.0.2
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-01-04 12:59:41 UTC
Category: ---
Cloudforms Team: ---
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
evm.log extract (7.75 KB, text/plain)
2016-08-18 15:39 UTC, Felix Dewaleyne
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:0012 0 normal SHIPPED_LIVE CFME 5.7.0 bug fixes and enhancement update 2017-01-04 17:50:36 UTC

Description Felix Dewaleyne 2016-08-18 15:39:44 UTC
Created attachment 1191923 [details]
evm.log extract

Description of problem:
after following the migration from 4.0 to 4.1 and running all the documented steps, a customer's evmserverd refuses to start with a seeding error

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

How reproducible:
all the time

Steps to Reproduce:
1. import the customer's database
2. upgrade his database
3.

Actual results:
[----] E, [2016-08-18T11:55:44.847313 #14856:397998] ERROR -- : [ActiveRecord::RecordInvalid]: Validation failed: Description has already been taken  Method:[rescue in block (2 levels) in seed]
[----] E, [2016-08-18T11:55:44.847584 #14856:397998] ERROR -- : /opt/rh/cfme-gemset/bundler/gems/rails-3d9d4f56c1ee/activerecord/lib/active_record/validations.rb:78:in `raise_validation_error'

Expected results:
the appliance starts

Additional info:
there is another issue (raised as 1367127) - for which the customer's db needed a truncate on miq_servers_product_updates table

Comment 3 Nick Carboni 2016-09-06 18:21:47 UTC
I can reproduce this issue upstream by changing the timezone from the default "UTC" to "London" on the default timeprofile.

Then restart evmserverd. This causes the app to fail to seed TimeProfile on startup because of the unique validation on the description.

We currently detect the default time profile by looking for the one that has the timezone "UTC". During seeding, if we can't find that profile we attempt to create it, which fails because the description has not changed on the original.

Comment 4 Nick Carboni 2016-09-06 19:24:07 UTC
https://github.com/ManageIQ/manageiq/pull/11040

Comment 5 Nick Carboni 2016-09-06 20:42:12 UTC
In the meantime another workaround for this issue would be to change the description on the original time profile. This would allow seeding to continue and you would also not lose anything which was previously referencing the original time profile.

Comment 6 CFME Bot 2016-09-13 02:40:54 UTC
New commit detected on ManageIQ/manageiq/master:
https://github.com/ManageIQ/manageiq/commit/93ed4d94c8bbcdb56802a2e5c165c567a465bfcb

commit 93ed4d94c8bbcdb56802a2e5c165c567a465bfcb
Author:     Nick Carboni <ncarboni>
AuthorDate: Tue Sep 6 15:17:41 2016 -0400
Commit:     Nick Carboni <ncarboni>
CommitDate: Tue Sep 6 15:17:41 2016 -0400

    Remove the unique validation on time_profiles description column
    
    This was causing an issue with seeding and determining the default
    time profile.
    
    If a user changes the timezone of the original seeded time profile,
    it is no longer recognized as the default because the timezone is
    not UTC. This causes us to attempt to seed a new time profile
    which could conflict by description.
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1368192

 app/models/time_profile.rb | 2 --
 1 file changed, 2 deletions(-)

Comment 7 Jan Krocil 2016-11-09 13:41:13 UTC
Verified fixed in 5.7.0.9 - 5.7.0.9-beta2.1.20161101182054_eb0afaa.

Comment 9 errata-xmlrpc 2017-01-04 12:59:41 UTC
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://rhn.redhat.com/errata/RHBA-2017-0012.html


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