Bug 1369262

Summary: [RFE] OpenStack infrastructure provider includes controller(s) in aggregate memory calculation
Product: Red Hat CloudForms Management Engine Reporter: nate stephany <nstephan>
Component: ProvidersAssignee: John Hardy <jhardy>
Status: CLOSED WONTFIX QA Contact: Dave Johnson <dajohnso>
Severity: medium Docs Contact:
Priority: medium    
Version: 5.6.0CC: dajohnso, jfrey, jhardy, kmorey, lavenel, obarenbo, tzumainn
Target Milestone: GAKeywords: FutureFeature
Target Release: cfme-futureFlags: lavenel: needinfo? (tzumainn)
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: openstack:infra:c&u
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-01-21 12:31:33 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description nate stephany 2016-08-22 21:37:07 UTC
Description of problem:
In the overview page for an OSP Director infrastructure provider, the "Aggregate Host / Node Memory" includes the memory available to the controller(s)

Version-Release number of selected component (if applicable):
5.6.1.2

How reproducible:
100%

Steps to Reproduce:
1. Add OSP director provider
2. Browse to overview page for provider
3.

Actual results:
In a 2 node (1 controller, 1 compute) enviornment, it shows 16 GB aggregate memory

Expected results:
It should only display the compute node memory...because no one really cares to include controller host memory in this type of statistic.

Additional info:

Comment 2 Tzu-Mainn Chen 2016-08-25 14:15:59 UTC
So the attribute being displayed is accurate; we can also break out the information by role, if you'd like.  In the meantime, I believe that you can view metrics by role under the role tab.

Comment 3 Tzu-Mainn Chen 2016-08-25 16:17:49 UTC
Actually, I just realized that I think this feature already exists.  If you go to the Deployment Roles tab and click on a particular role, you'll see aggregated metrics that should match what you're looking for.

Comment 4 nate stephany 2016-08-25 18:53:13 UTC
(In reply to Tzu-Mainn Chen from comment #3)
> Actually, I just realized that I think this feature already exists.  If you
> go to the Deployment Roles tab and click on a particular role, you'll see
> aggregated metrics that should match what you're looking for.

it is good that it is already in there. However, please consider making this change to the summary page for the provider. I can't imagine a scenario where someone would care to include the cpu/mem capacity of controllers in the summary of aggregate resources in a cloud cluster. That would be like including the cpu/mem for the vcenter or rhev manager with the summary of those providers.

Comment 6 Loic Avenel 2016-09-15 20:17:53 UTC
I think there are two use cases here: 

- Infra Person wants to know how much hardware the have in CPU/Memory...

- OpenStack admin wants to know how much compute resources they have.

I think for Nate scenario, of you go in the Deployment Role place which is not really nice OR just create a Widget in the dashboard.

We should not change anything for now.

Comment 7 nate stephany 2016-09-15 21:15:33 UTC
(In reply to Loic Avenel from comment #6)
> I think there are two use cases here: 
> 
> - Infra Person wants to know how much hardware the have in CPU/Memory...
> 
> - OpenStack admin wants to know how much compute resources they have.
> 
> I think for Nate scenario, of you go in the Deployment Role place which is
> not really nice OR just create a Widget in the dashboard.
> 
> We should not change anything for now.

But when would anyone look at an OpenStack provider and want to see the controller cpu/memory calculated in the total available to that provider? That memory and cpu is not available as capacity for VMs to use. If I wanted to see my controller cpu & memory, then I should have to go look at a deployment role or dig for it some more since it is not something people are going to be looking at on a regular basis. 

Again, this is like looking at the VMware provider and having the vCenter cpu & memory included in the aggregate total. Doesn't make any sense.

Comment 8 Loic Avenel 2016-09-16 17:45:45 UTC
I really understand the use case but I think we have a more elegant way to solve this.