Bug 1630446

Summary:	[V2V] Migration plan scheduling widget shows the wrong time
Product:	Red Hat CloudForms Management Engine	Reporter:	Eric Lavarde <elavarde>
Component:	UI - OPS	Assignee:	Brett Thurber <bthurber>
Status:	CLOSED WORKSFORME	QA Contact:	Kedar Kulkarni <kkulkarn>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	5.9.4	CC:	akarve, awight, bthurber, dmetzger, elavarde, hkataria, kkulkarn, lavenel, mfeifer, mpovolny, obarenbo
Target Milestone:	GA
Target Release:	5.9.6
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	v2v
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-10-18 18:19:47 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	V2V	Target Upstream Version:
Embargoed:

Description Eric Lavarde 2018-09-18 16:44:07 UTC

Description of problem:

When scheduling a migration plan, the calendar/time widget shows a certain time (which is apparently the current time), but once selected, the time shown (and acted upon) is 6 hours later, meaning that it makes the scheduling quite unpredictable (especially because it's unclear where the 6 hours are coming from).

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

Version 5.9.4.4.20180816162527_c00eb23 

How reproducible:

Always (using the RHPDS demo environment)

Steps to Reproduce:
1. Go to CFME -> Compute -> Migration
2. Create a mapping
3. Create a plan, save it (don't start it)
4. Press the [Schedule] button
5. Select a date and time using the calendar widget
6. Save

Actual results:

The time shown in the CFME Web UI is 6 hours later than the one chosen in the calendar widget. I didn't wait, but the time effectively scheduled was probably the time shown then in the Web UI (and not the time selected).

Expected results:

The time is the same (and probably my local time, or it starts to be confusing). Even more flexible would be the possibility to define time _and_ timezone.

Additional info:

- changing the timezone of the appliance in the CFME UI didn't make any difference (it was initially UTC, changed it to New York).
- the timezone of the conversion server and of the appliance was (on the command line) EDT.
- my local timezone (browser time, so to say) is CEST.

Comment 2 Dave Johnson 2018-09-18 16:44:24 UTC

Please assess the impact of this issue and update the severity accordingly.  Please refer to https://bugzilla.redhat.com/page.cgi?id=fields.html#bug_severity for a reminder on each severity's definition.

If it's something like a tracker bug where it doesn't matter, please set the severity to Low.

Comment 4 Eric Lavarde 2018-10-02 07:14:41 UTC

I set the severity to high because it is something that can be very confusing.

Especially as IMS is targeting at big migrations, the impact of a wrong time calculation can be high, like the migration happening outside of the foreseen maintenance window, clogging the network and/or the storage at the wrong moment.

Comment 5 Brett Thurber 2018-10-02 21:07:11 UTC

(In reply to Eric Lavarde from comment #4)
> I set the severity to high because it is something that can be very
> confusing.
> 
> Especially as IMS is targeting at big migrations, the impact of a wrong time
> calculation can be high, like the migration happening outside of the
> foreseen maintenance window, clogging the network and/or the storage at the
> wrong moment.

Did you set the proper time zone on the appliance prior to scheduling a migration?  The RHPDS env used for RHTE was based in the US so I expect the 6 hour difference.  When configuring CloudForms, setting the correct time zone on the appliance will be the resolution for this.

Comment 6 Eric Lavarde 2018-10-04 07:23:52 UTC

Hi Brett, no I didn't, but I don't think this is the point here: you might always have different time zones involved in a migration environment, and it's kind of OK (not optimal though) to have a timezone shift involved, but then it should be at least consistent for the user, and not be different in the date/time selection dialog and how it then appears and is executed in the WebUI.

Additionally, the time zone difference of the appliance should IMHO be addressed by the setting of such in the CFME UI (see my first additional info "changing the timezone of the appliance in the CFME UI didn't make any difference").

Comment 7 Kedar Kulkarni 2018-10-08 20:01:23 UTC

I did try to reproduce it. I changed my compute time to CEST and appliance time to Eastern Timezone(US), but when I scheduled migration, it showed the time based on what my computer/browser timezone was set to.

Comment 8 Brett Thurber 2018-10-09 03:40:13 UTC

(In reply to Kedar Kulkarni from comment #7)
> I did try to reproduce it. I changed my compute time to CEST and appliance
> time to Eastern Timezone(US), but when I scheduled migration, it showed the
> time based on what my computer/browser timezone was set to.

This may be just a weird Ravello thing in RHPDS.

Comment 9 Eric Lavarde 2018-10-09 07:20:25 UTC

Or perhaps it's the time of the conversion server and not of the appliance which is relevant? (not excluding a Ravello weirdness, though)

Comment 10 Eric Lavarde 2018-10-09 07:25:58 UTC

Sorry, I realize that I might have misunderstood what is meant with "compute" time in Comment #7. I see 3 relevant times:

1. the time of the user's browser/PC
2. the time of the CFME appliance(s)
3. the time of the conversion server

There are also the times of the hypervisors and of the converted VMs but I doubt they are relevant (well, you know better your code).

AFAICJ, my browser time was CEST, other times were EST.

Comment 17 Brett Thurber 2018-10-17 04:31:35 UTC

@KK can you test changing appliance time and local time on your machine to verify what time the scheduler is picking up?

Thanks!

Comment 22 CFME Bot 2018-10-18 14:23:01 UTC

https://github.com/ManageIQ/manageiq-v2v/pull/721

Comment 26 Brett Thurber 2018-10-18 18:19:47 UTC

Moving to closed as unable to reproduce.