Tal, the bug is on infra and Dima assigns to it. He started that work in 4.3.2014 and it's on advanced progress. those patches are partial in vdsm side and engine, it doesn't include the ui and restapi parts. we discussed about the way and place to add the uptime value and you were not in that loop at all. please say something before taking over . im moving the bug back to infra to let dima finish the work ..
A lot of arguments around the implementation. Nir, Roy please share your thoughts here. from what i understand: 1. you want to ask dima- why do you convert to date instead of doing that in engine's side 2. you want to understand why does dima want to use the TimeZone and if it can lead to mismatch 3. why is it on vdsDynamic and not vdsStatics right?
When I began working on it I talked to danken and barak, and danken suggested that we should calculate the boot time once on vdsm side and encode it in a non ambiguous way for the engine, and then always return the same value (until the next reboot). About the timezone, I think it is exactly the opposite, since engine might be in one timezone and the host in another, it is important to include the timezone host is located in, so the boot time can make sense. About the dynamics vs statics, statics look like things that are configured or decided upon host creation, and unlikely to change, while dynamics look like things that are likely to change during host life-cycle, like boot time.
Time zones are for humans. All host-to-host communications must be done in UTC. Reporting the boot time (instead of elapsed time since boot) seems like a cleaner API to me (it does not change, you do not care when the sample was taken). But I do not have much beyond gut feeling for this. grep btime /proc/stats would put the burden of "calculation" on the kernel.
1. btime is the seconds from epoch the machine started so actually no calculation is involved. perfect actually. its time zone free, plain and simple. the client(i.e engine) can do whatever it needs with it. we should store it as is, just a number. this also means we should name the field in DB and Entities as boot_time. uptime can be calculated by any of the clients accordingly. 2. Dima I think there's a confusion around static and statistics. I am referring to storing this in vds_statistics table. engine pulls host stats less frequent than dynamics and with a good reason. boot time isn't something which varies a lot. this is also symmetric with the name /proc/stats, which has also cpu stats which would also be a part of statistics as well in a short while.
Is the customer interested in the machine uptime (22 hours, 3 minutes) or the machine boot time (e.g. Apr 3, 09:05)? If the purpose of this is showing the uptime, the best way to do it is getting the uptime from /proc/uptime. If we use btime from /proc/stat, we must read this value on each request, and compare it with the current host time. If the host time changes, btime also changes: $ grep btime /proc/stat btime 1396342235 Now change the time on the machine one to an hour later: $ grep btime /proc/stat btime 1396345821 We certainly cannot take the boot time *once* from the host, and use the engine time for calculating the uptime. The host time is unlikely to change these days, but I don't see the need to "optimize" the uptime getting operation. I don't understand why we did not took the trivial patch suggest by Tal: http://gerrit.ovirt.org/#/c/25835
Implementing something along the lines of "Boot time: April 22, 2014 15:45 (up 3 days 7 minutes)." would be best, however if it can only be uptime or boot time, uptime is preferred.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2015-0158.html