Bug 1371764 - Running build's duration is not correct on build page when local time is not sync with server
Summary: Running build's duration is not correct on build page when local time is not ...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Management Console
Version: 3.3.0
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: ---
: ---
Assignee: Jessica Forrester
QA Contact: Yadan Pei
URL:
Whiteboard:
: 1377868 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-08-31 03:35 UTC by Xingxing Xia
Modified: 2019-10-28 13:53 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-10-28 13:53:28 UTC
Target Upstream Version:


Attachments (Terms of Use)
Duration on build page (139.64 KB, image/png)
2016-08-31 03:35 UTC, Xingxing Xia
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1377868 0 medium CLOSED Build time is incorrect in OSE web console 2021-02-22 00:41:40 UTC

Internal Links: 1377868

Description Xingxing Xia 2016-08-31 03:35:41 UTC
Created attachment 1196156 [details]
Duration on build page

Description of problem:
On build page, there includes 2 lines:
Started:       8 minutes ago ...
Duration:     running for ... minutes, ... seconds

While in CLI, the output of `oc get build` also includes "STARTED" and "DURATION" (in columns).
The above 2 lines on build page correspond to the 2 columns in CLI.

However, given local date is not sync with server, when a build is running, its duration is not correct on build page, which is calculated by "local time - build's metadata.creationTimestamp". This is wrong and does not correspond to the DURATION value in `oc get build`.
Note: but after the build is complete, its Duration on build page suddenly changes to as correct as CLI shows.

Version-Release number of selected component (if applicable):
openshift v3.3.0.27

How reproducible:
Always

Steps to Reproduce:
1. Start a build
2. When build is running:
1> Check the value after "Duration" on build page https://<master>:8443/console/project/<your_project>/browse/builds/<bc>/<build>
2> Check the duration via CLI
$ oc get build


Actual results:
2. The value after "Duration" seems calculated by "local time - build's metadata.creationTimestamp". When local time is not sync with server, it is wrong. Here are an example in which case local time is about 7 mins earlier than server:
1> See attachment, Duration begins from 7 mins and increments every seconds
2> $ oc get build
NAME                  TYPE     FROM         STATUS   STARTED         DURATION
ruby-sample-build-2   Source   Git@e79d887  Running  8 minutes ago   30s


Expected results:
2.
1> Duration should be displayed like DURATION column of `oc get build`

Additional info:
This bug is not talking about "Started" but "Duration".
Though the "Started" line/column is wrong too, it would not be fixed as per https://bugzilla.redhat.com/show_bug.cgi?id=1299328#c2

Comment 2 Jessica Forrester 2016-09-21 13:34:48 UTC
*** Bug 1377868 has been marked as a duplicate of this bug. ***

Comment 3 Jessica Forrester 2016-09-21 21:17:02 UTC
The CLI only needs to make a single request, the API is calculating duration at the time of the GET request and returning it.  The console on the other hand is getting the build and then opening a websocket to watch for changes to the build. We get the initial value of duration calculated by the API, but since there is no change to actual stored data no watch event is fired so we never get an updated duration from the server.

Comment 4 Jessica Forrester 2016-11-21 15:09:34 UTC
Also see https://github.com/openshift/origin/issues/2568

Comment 5 Samuel Padgett 2019-10-28 13:53:28 UTC
In 4.x, we calculate the build duration using the value from the API, so this should be a non-issue: https://github.com/openshift/console/blob/88dc7f8343826e710e052ec559657648cd97a07a/frontend/public/module/k8s/builds.ts#L42-L56


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