Bug 918152

In order to fully fix this bug for 3.2.0 I need a way to know engine is updating the statistics. Please add a variable to dwh_history_timekeeping with a var_name like lastStatisticsUpdate and update the var_datetime column on every update of a statistics table (of any entity).



Yaniv


+++ This bug was initially created as a clone of Bug #913384 +++

Created attachment 700378 [details]
dwhd servce down

Description of problem:
Cannot Start DWHd service & Receiving Error Can't start the ovirt-engine-dwhd service when upgrading from si25.4 to si27.1 with reports

Version-Release number of selected component (if applicable):
3.1/si27.1 - si25.4

How reproducible:
always

Steps to Reproduce:
1.Install rhevm30 ic158.2 with reports + dwh
2.aggregate data for 2D
3.Upgrade to rhevm31/si24.5 (3.1.1)
  Upgrade reports & dwh & run setup
4.aggregate data for 2D
5.Upgrade to rhevm31/si27.1 (3.1.3)

  
Actual results:
when rhevm-upgrade finishes service DWHd is stopped & I get error:
* Error: Can't start the ovirt-engine-dwhd service 


Expected results:
dwhD service should start & no error should be displayed

Additional info:
3.1/si25.4 upgraded to si27.1

Is it a known issue ? (Can't start the ovirt-engine-dwhd service)

Would you like to proceed? (yes|no): y
Stopping ovirt-engine service...                         [ DONE ]
Stopping DB related services...                          [ DONE ]
Cleaning async tasks...                                  [ DONE ]
Pre-upgrade validations...                               [ DONE ]
Backing Up Database...                                   [ DONE ]
Rename Database...                                       [ DONE ]
Updating rpms (This may take a while
depending on your connection speed to the repository.
To track the installation process run tail -f /var/log/yum.log in
another session).
Note that the transition from package removal to package installation
is expected
to take a significant amount of time. No output will appear in the log
file during
this transition.... [ DONE ]
Updating Database...                                     [ DONE ]
Restore Database name...                                 [ DONE ]
Running post install configuration...                    [ DONE ]
Starting ovirt-engine...                                 [ DONE ]

RHEV Manager upgrade completed successfully!

* Error: Can't start the ovirt-engine-dwhd service

--- Additional comment from David Botzer on 2013-02-21 10:44:26 EST ---

reproduced also on 
3.2/SF8

I upgraded SF7 to SF8 while dwhd service failed to start automatically,
needs to start manually.

--- Additional comment from David Botzer on 2013-02-21 10:46:07 EST ---

Created attachment 700609 [details]
SF7-SF8

--- Additional comment from Yaniv Dary on 2013-02-25 06:45:12 EST ---

Checked the logs the service did start ok nd had return code 0.
The upgrade returned error anyway. Moving to integration to check upgrade.




Yaniv

--- Additional comment from Yaniv Dary on 2013-02-25 07:54:29 EST ---

Please add log of the dwh post upgrade with the error.



Yaniv

--- Additional comment from David Botzer on 2013-02-25 08:11:32 EST ---

which log ?
see all logs in GZ

--- Additional comment from David Botzer on 2013-02-25 08:12:02 EST ---

Created attachment 702344 [details]
si27.1

--- Additional comment from David Botzer on 2013-02-25 08:22:09 EST ---

Created attachment 702355 [details]
SF-7-SF-8

--- Additional comment from Yaniv Dary on 2013-02-25 08:25:27 EST ---

(In reply to comment #7)
> Created attachment 702355 [details]
> SF-7-SF-8

The files are corrupt.

--- Additional comment from Idith Tal-Kohen on 2013-02-28 10:25:50 EST ---

This bug was cloned to the z-stream:
https://bugzilla.redhat.com/show_bug.cgi?id=916643

--- Additional comment from Cheryn Tan on 2013-03-04 01:12:16 EST ---

Hi Moran, you mentioned on virt-program-list that this bug (or its corresponding 3.1.z clone) needs documentation in the release notes. Can you please provide more information on what causes the ovirt-engine-dwhd to fail to start, and the recommended workaround? Thank you!

--- Additional comment from RHEL Product and Program Management on 2013-03-05 05:51:36 EST ---

This bug report previously had all acks and release flag approved.
However since at least one of its acks has been changed, the
release flag has been reset to ? by the bugbot (pm-rhel).  The
ack needs to become approved before the release flag can become
approved again.