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:
We collect volume types (if defined in OpenStack) to entity named CloudVolume. The problem is that not every vm has a volume.
Can you specify further on that? In what cases we get the VM has a volume and when it doesn't
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.
https://github.com/ManageIQ/manageiq/pull/11867
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(+)
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?
https://github.com/ManageIQ/manageiq/pull/12530
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
could we get an update about this RFE please
There is nothing to update since the comment 14 (7 days ago).
Hi, could you update about this Bugzilla please.
Hi could we get an update about the Bugzilla please.
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
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