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):
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
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).
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.
- 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.
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.
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.
(In reply to Eric Lavarde from comment #4)
> I set the severity to high because it is something that can be very
> 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.
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").
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.
(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.
Or perhaps it's the time of the conversion server and not of the appliance which is relevant? (not excluding a Ravello weirdness, though)
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.
@KK can you test changing appliance time and local time on your machine to verify what time the scheduler is picking up?
Moving to closed as unable to reproduce.