Bug 1375506

Summary: [RFE] Charge volume types differently.
Product: Red Hat CloudForms Management Engine Reporter: Edu Alcaniz <ealcaniz>
Component: ReportingAssignee: Libor Pichler <lpichler>
Status: CLOSED ERRATA QA Contact: Nandini Chandra <nachandr>
Severity: high Docs Contact:
Priority: high    
Version: 5.6.0CC: cpelland, dajohnso, ealcaniz, gtanzill, hhudgeon, jfrey, jhardy, jrafanie, lavenel, lpichler, maufart, obarenbo, simaishi, slukasik, soconcar
Target Milestone: MVPKeywords: FutureFeature
Target Release: 5.9.0   
Hardware: x86_64   
OS: Linux   
Whiteboard: chargeback:volume
Fixed In Version: 5.9.0.5 Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-03-01 13:07:41 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: Feature
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: CFME Core Target Upstream Version:
Embargoed:

Description Edu Alcaniz 2016-09-13 09:28:11 UTC
Description of problem:
We would like to charge differently each OpenStack type of volume.
For example: an instance with an SSD disk for OS and one other (HDD) for data. At the moment must be charged at same price.


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


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:
At the moment must be charged at same price for different hw

Expected results:
It's possible to implement this feature?

Additional info:

Comment 5 Šimon Lukašík 2016-10-05 11:48:52 UTC
We collect volume types (if defined in OpenStack) to entity named CloudVolume. The problem is that not every vm has a volume.

Comment 6 Sergio Ocón-Cárdenas 2016-10-05 12:49:17 UTC
Can you specify further on that?

In what cases we get the VM has a volume and when it doesn't

Comment 7 Šimon Lukašík 2016-10-05 13:56:07 UTC
More info: In OpenStack, the instance can have multiple cloud volumes and it has one or more disks.

For cloud volumes, we collect the type from the OpenStack provider. However that type is whatever openstack's user puts in. For disks, it seems, we do not collect disk_type as of now.

The problem arises when a Vm has multiple disks. When we store metrics in Metrics table, we already work with aggregate total. If we want the ability to calculate cost based on SSD and HDD usage separately, we need to put this into Metrics table (or VimPerformanceState as suggested by Gregg).

It seems we don't keep & calculate metrics of CloudVolumes so that (nova volume-type-list) seems unrelated.

Comment 10 CFME Bot 2016-10-19 12:46:26 UTC
New commit detected on ManageIQ/manageiq/master:
https://github.com/ManageIQ/manageiq/commit/bb26ccca5dcc03cb096dfbbc9c9f0cea053b3691

commit bb26ccca5dcc03cb096dfbbc9c9f0cea053b3691
Author:     Šimon Lukašík <isimluk>
AuthorDate: Tue Oct 11 09:50:28 2016 +0200
Commit:     Šimon Lukašík <isimluk>
CommitDate: Wed Oct 19 12:31:12 2016 +0200

    Store disk types in VimPerformanceState
    
    Disk types may differ in costs associated to them. This data can be
    later used in Chargeback calculation.
    
    At this point we capture only storage allocation and not usage, as we
    don't always refresh per-disk usage from providers.
    
    This is first step for
    https://bugzilla.redhat.com/show_bug.cgi?id=1375506

 app/models/vim_performance_state.rb       | 11 +++++++++++
 spec/models/vim_performance_state_spec.rb | 17 +++++++++++++++++
 2 files changed, 28 insertions(+)

Comment 11 Jorge 2016-11-07 21:46:41 UTC
We have similar requirement coming from Openshift users.

They would like to be able to make chargeback based on differents flavors (quality) of Persisten Volumes (not just if the volume is persistent or not persistent)

Is it  possible to implement this feature?

Comment 14 Šimon Lukašík 2017-06-07 07:20:49 UTC
This turned out to be little more harder to implement than what we originally thought. This is still work in progress.


The reasons for that is that it needs us to introduce new *type of types* of ChargeabackRateDetail. Previous design of ChargebackRateDetail did not allowed for that https://github.com/ManageIQ/manageiq/issues/13375 The other problem we tackled was that rate-editor-ui is very complex and clumsy, so we need to make it light weight, before we start adding storage types (volume types).

Relevant not-yet-merged prs are 
 - https://github.com/ManageIQ/manageiq/pull/12501
 - https://github.com/ManageIQ/manageiq/pull/12850

TODO:
 - finish decoupling of ChargeableField from ChargebackRateDetail (almost done)
 - Simlify rate editor (when we have chargeableField enum, we don't need default rates and rate editor can be angular based wizard)
 - Introduce volume types to the new wizard-like rate-editor

Comment 15 Edu Alcaniz 2017-06-14 08:30:02 UTC
could we get an update about this RFE please

Comment 16 Šimon Lukašík 2017-06-14 08:51:11 UTC
There is nothing to update since the comment 14 (7 days ago).

Comment 18 Edu Alcaniz 2017-08-17 08:19:48 UTC
Hi, could you update about this Bugzilla please.

Comment 22 Edu Alcaniz 2017-10-15 14:11:50 UTC
Hi could we get an update about the Bugzilla please.

Comment 30 Nandini Chandra 2017-12-18 23:20:42 UTC
https://bugzilla.redhat.com/show_bug.cgi?id=1517956 occurs only when a new volume type is added or when an existing volume type is modified.

So, I'm marking this BZ as VERIFIED

Comment 33 errata-xmlrpc 2018-03-01 13:07:41 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.

https://access.redhat.com/errata/RHSA-2018:0380