Bug 1286847

Summary:	The web interface shows exclamations about timezone, but timezones are configured
Product:	[oVirt] ovirt-engine	Reporter:	Paul <paul>
Component:	Frontend.WebAdmin	Assignee:	bugs <bugs>
Status:	CLOSED DUPLICATE	QA Contact:	Pavel Stehlik <pstehlik>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	3.6.0	CC:	bugs, ecohen, tjelinek, v.astafiev
Target Milestone:	---	Flags:	rule-engine: planning_ack? rule-engine: devel_ack? rule-engine: testing_ack?
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:	virt
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-12-16 09:22:10 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Paul 2015-11-30 21:36:50 UTC

Description of problem:

The web interface shows exclamations about timezone and says "Actual timezone in guest differs from the configuration".

Maybe same problem Guest info shows nothing?
http://screencast.com/t/JejTsLAxuXw


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


How reproducible:

I upgraded on Centos 6 ( so vdsmd not upgraded ).
I have guest-agent runnning
I had to sync time for spacewalk, so installed ntpd and quite sure time is correct.
I have set correct timezone in web interface panel ( edit > System > General => GMT+1 )
when I check date is shows "CET"

I see there are multiple GMT+1 entries in the web Gui: 
"(GMT+01:00) Central Europe Standard Time"
"(GMT+01:00) Central European Standard Time"

Are all GMT+1 the same or what is the difference above these two?

Actual results:

Warning about mismatch ( and under Guest info no results )

Expected results:

Timezone info under Guest info and no exclamation mark.

Additional info:

All run on Centos 6 with shared FC storage.
All hosts and hosted engine have been restarted since upgrade.
So running in 3.5 compatibility mode, because no vdsdm upgrade possible.

Comment 1 Tomas Jelinek 2015-12-16 09:22:10 UTC

According to the discussion on users list this same issue has been tracked also here: https://bugzilla.redhat.com/show_bug.cgi?id=1286937

Only one BZ was supposed to be opened for it and since the 1286937 already contains the patches, closing this one as duplicate.

*** This bug has been marked as a duplicate of bug 1286937 ***