Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1070348 - PRD35 - [RFE] RHEVM GUI - Add host uptime information to the "General" tab
Summary: PRD35 - [RFE] RHEVM GUI - Add host uptime information to the "General" tab
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.3.0
Hardware: x86_64
OS: Linux
Target Milestone: ---
: 3.5.0
Assignee: Dima Kuznetsov
QA Contact: Petr Matyáš
Whiteboard: infra
Depends On: 1090798
Blocks: rhev3.5beta 1156165
TreeView+ depends on / blocked
Reported: 2014-02-26 16:17 UTC by Robert McSwain
Modified: 2019-03-22 07:13 UTC (History)
18 users (show)

Fixed In Version: vt1.3
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2015-02-11 17:58:31 UTC
oVirt Team: Infra
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:0158 normal SHIPPED_LIVE Important: Red Hat Enterprise Virtualization Manager 3.5.0 2015-02-11 22:38:50 UTC
oVirt gerrit 25877 None None None Never
oVirt gerrit 25879 None None None Never
oVirt gerrit 25880 None None None Never

Comment 1 Yaniv Bronhaim 2014-03-19 07:46:45 UTC
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 ..

Comment 3 Yaniv Bronhaim 2014-03-24 13:17:25 UTC
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


Comment 4 Dima Kuznetsov 2014-03-24 19:32:54 UTC
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.

Comment 5 Dan Kenigsberg 2014-03-24 22:27:17 UTC
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.

Comment 6 Roy Golan 2014-03-25 08:14:08 UTC
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.

Comment 7 Nir Soffer 2014-04-03 06:50:31 UTC
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:

Comment 8 Robert McSwain 2014-05-23 13:18:53 UTC
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.

Comment 11 errata-xmlrpc 2015-02-11 17:58:31 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.