Bug 1275918 - [userinterface_public_525]Available number is not matched with used number in pod metrics chart when choose different "Time Range"
Summary: [userinterface_public_525]Available number is not matched with used number in...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: OKD
Classification: Red Hat
Component: Management Console
Version: 3.x
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: ---
Assignee: Samuel Padgett
QA Contact: Yanping Zhang
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-10-28 06:30 UTC by Yanping Zhang
Modified: 2015-11-23 21:15 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-11-23 21:15:43 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
last-hour (63.77 KB, image/png)
2015-10-28 06:31 UTC, Yanping Zhang
no flags Details
last-week (63.29 KB, image/png)
2015-10-28 06:32 UTC, Yanping Zhang
no flags Details
30-minutes (61.16 KB, image/png)
2015-10-28 06:32 UTC, Yanping Zhang
no flags Details

Description Yanping Zhang 2015-10-28 06:30:59 UTC
Description of problem:
Check pod's metrics on web console, the available number is not matched with used number when choose different Time Range. The sum of available number and used number is not equal to the total number. It confused user how many resources are used.

Version-Release number of selected component (if applicable):
openshift v1.0.6-997-gff3b522
kubernetes v1.2.0-alpha.1-1107-g4c8e6f4
etcd 2.1.2

How reproducible:
Always

Steps to Reproduce:
1.Setup metrics. Create pod with cpu/memory requests/limits.
1.1 oc run cpuhog --image=busybox --requests=cpu=100m --limits=cpu=500m -- md5sum /dev/urandom
1.2 $oc create -f origin/examples/project-quota/application-template-with-resources.json -n pro1
$oc new-app ruby-helloworld-sample-with-resources 
2.Login on web console, check pod cpuhog's metrics, switch "Time Range" in list: "Last 30 minutes, Last hour, Last 4 hours, Last day, Last week" 
3.Check app's pod metrics such as frontend/database , switch "Time Range" in list: "Last 30 minutes, Last hour, Last 4 hours, Last day, Last week" 

Actual results:
2,3.The available number is not matched with used number for some Time Range. The sum of available number and used number is not equal to the total number. Refer to the attachment.

Expected results:
2,3.Should have right number for any Time Range, and make it clear for users.

Additional info:

Comment 1 Yanping Zhang 2015-10-28 06:31:45 UTC
Created attachment 1087148 [details]
last-hour

Comment 2 Yanping Zhang 2015-10-28 06:32:20 UTC
Created attachment 1087149 [details]
last-week

Comment 3 Yanping Zhang 2015-10-28 06:32:51 UTC
Created attachment 1087150 [details]
30-minutes

Comment 4 Samuel Padgett 2015-10-28 11:38:02 UTC
I suspect this is an angular-patternfly utilization chart bug since we don't calculate the available value, we only give them used and total. It looks like they're not watching changes to those values to update available.

https://github.com/patternfly/angular-patternfly/blob/master/src/charts/utilization/utilization-chart-directive.js

We should be able to set the available value ourselves to workaround the problem, although I'd like to open an upstream issue as well.

/cc Jessica

Comment 5 Samuel Padgett 2015-10-28 14:58:23 UTC
Opened an upstream angular-patternfly pull request to fix:

https://github.com/patternfly/angular-patternfly/pull/143

Comment 6 Samuel Padgett 2015-10-29 02:10:17 UTC
origin pull request:

https://github.com/openshift/origin/pull/5475

Comment 7 Yanping Zhang 2015-10-30 06:01:05 UTC
Tested on latest origin code.
openshift v1.0.7-32-gd17e473
kubernetes v1.2.0-alpha.1-1107-g4c8e6f4
etcd 2.1.2

Login on web console, check pod's metrics, switch "Time Range" in list: "Last 30 minutes, Last hour, Last 4 hours, Last day, Last week". Now the available number is matched with used number for all Time Range, and the sum of available number and used number is equal to the total number. 

The bug has been fixed, so move it to verified.


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