Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1152557

Summary:	broken timezone handling in dwh
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	movciari
Component:	ovirt-engine-dwh	Assignee:	Shirly Radco <sradco>
Status:	CLOSED NOTABUG	QA Contact:	movciari
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	3.5.0	CC:	ecohen, gklein, iheim, lsurette, movciari, pmatyas, pstehlik, rbalakri, Rhev-m-bugs, yeylon, ylavi
Target Milestone:	---	Keywords:	Reopened, Triaged
Target Release:	3.5.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	infra
Fixed In Version:		Doc Type:	Release Note
Doc Text:	In separate hosts installation of dwh & reports all servers must be synced with the same ntp time server for correct data to be saved.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-11-12 12:00:49 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Infra	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1133608

Description movciari 2014-10-14 12:08:58 UTC

Description of problem:
i have engine and dwh both in +2 timezone, and in dwh tables this is handled incorrectly
in dwh_history_timekeeping in engine db i have last sync 2014-10-14 15:03:00+02
in v3_5_statistics_hosts_resources_usage_hourly in dwh db same sync has history_datetime set to 2014-10-14 13:00:00+02
it can't be old data in dwh db because it was stopped and i started it only half an hour ago, so it's wrong handling of timezone

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

How reproducible:
always

Steps to Reproduce:
1. install engine with +2 timezone
2. install dwh with +2 timezone
3. wait for hourly data aggregation
4. check timestamp in v3_5_statistics_hosts_resources_usage_hourly

Comment 1 Shirly Radco 2014-10-14 12:27:54 UTC

(In reply to movciari from comment #0)
> Description of problem:
> i have engine and dwh both in +2 timezone, and in dwh tables this is handled
> incorrectly
> in dwh_history_timekeeping in engine db i have last sync 2014-10-14
> 15:03:00+02
> in v3_5_statistics_hosts_resources_usage_hourly in dwh db same sync has
> history_datetime set to 2014-10-14 13:00:00+02
> it can't be old data in dwh db because it was stopped and i started it only
> half an hour ago, so it's wrong handling of timezone
> 
> Version-Release number of selected component (if applicable):
> vt5
> 
> How reproducible:
> always
> 
> Steps to Reproduce:
> 1. install engine with +2 timezone
> 2. install dwh with +2 timezone
> 3. wait for hourly data aggregation
> 4. check timestamp in v3_5_statistics_hosts_resources_usage_hourly

Is the time is set correctly in the 2 hosts?
Meaning they are set to the same exact hour.(not just timezone)
If they are not, then the difference is by design and this bug should be closed.

Comment 2 movciari 2014-10-20 14:07:48 UTC

no, time is set incorrectly on machine with dwh because i wanted to test it...
time in dwh db should be set according to engine db time, there is a bug for that.
if it's set incorrectly, it's definitely not by design...

Comment 3 Shirly Radco 2014-10-20 14:12:26 UTC

We are not responsible to check current time according to the chosen timezone.
This is the system administrators responsibility.
So this is left for him by design.
We do handle different timezones for engine and dwh.

Shirly

Comment 4 movciari 2014-10-20 14:19:56 UTC

yes, but if you don't want to handle timezone, you should use timestamp without timezone... current state is that you put UTC time there and say it's UTC+2 time because you use a timezone

Comment 5 Yaniv Lavi 2014-10-28 12:58:58 UTC

(In reply to movciari from comment #4)
> yes, but if you don't want to handle timezone, you should use timestamp
> without timezone... current state is that you put UTC time there and say
> it's UTC+2 time because you use a timezone

All machines are required to be synced according to same ntp time server.
We can not check this is it out of scope. I'll add docs flag to note this in release notes, but I'm closing this as this is not a bug.

Comment 6 movciari 2014-10-29 10:18:20 UTC

now i have the same time on all machines, set by the same ntp server, and with the same timezone, i can still reproduce this bug

Comment 7 movciari 2014-10-29 10:22:48 UTC

dwh always shows UTC time, but says it's in some other timezone...
example:
data was collected 2014-10-29 11:00:00+01 which is 2014-10-29 10:00:00 UTC
dwh shows it was collected 2014-10-29 10:00:00+01

you should either change dwh to show timestamp without timezone and say in documentation that it shows UTC time or fix the timezone handling

Comment 8 Shirly Radco 2014-11-06 08:39:37 UTC

Please check samples tables, not hourly.
Hourly tables aggregate the records for the hour before last.

Example: at 10 AM records will be aggregated for 8-9 AM and after that the "lastHourAggr" in history_configuration tabke will be set to 9AM.

Comment 9 Yaniv Lavi 2014-11-11 15:04:52 UTC

Michal, we are waiting on you reply, please respond,

Comment 10 Petr Matyáš 2014-11-12 11:19:31 UTC

When I check the samples table I can see entries in local timezone, as well as in engine db, so you can close it.