Bug 1168021

Summary:	[RFE] Report Storage IOPS cumulative values per VM per disk via metric store.
Product:	[oVirt] ovirt-engine-metrics	Reporter:	Zaharioudakis Nikos <nzahar>
Component:	RFEs	Assignee:	Shirly Radco <sradco>
Status:	CLOSED DUPLICATE	QA Contact:	Lukas Svaty <lsvaty>
Severity:	low	Docs Contact:
Priority:	high
Version:	unspecified	CC:	amureini, bugs, lsurette, mgoldboi, rbalakri, sradco, srevivo, ykaul, ylavi
Target Milestone:	ovirt-4.2.0	Keywords:	FutureFeature
Target Release:	---	Flags:	ylavi: ovirt-4.2? lsvaty: testing_plan_complete- mgoldboi: planning_ack+ ylavi: devel_ack? pstehlik: testing_ack+
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-07-31 08:20:54 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Metrics	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	876697, 1317433
Bug Blocks:	1168026

Description Zaharioudakis Nikos 2014-11-25 21:54:08 UTC

Description of problem:

Following a nice discussion in the ovirt mailing list about a billing solution
It would be really nice to be in the position to gather this info per vm so that through an interface GUI invoices could be generated for post paid plans and according to the plans the admin can set. 

Version-Release number of selected component (if applicable): 1.x :-) meaning it would be a helpful feature to exist already


Expected results: Perhaps a nice minimal billing web app with a separate database that holds the usage information that has the possibility to either generate minimalistic invoices based on plans set by the admin, or access the info through an API from a centralized billing.


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

 Interesting aspect would be the actual usage of a customer's vm to be charged in comparison to the provisioned.



Additional info: I picked up the reports as it is the closest component I could think of

Comment 3 Yaniv Kaul 2016-04-27 18:40:50 UTC

Moving to 4.1, due to dependant bugs that are for 4.1 as well.

Comment 4 Lukas Svaty 2016-11-23 14:01:47 UTC

Can we clarify what is the end result here? What is necessary for testing?

Comment 5 Shirly Radco 2017-06-29 07:26:09 UTC

I don't think there is any update on this.
It is still dependent on bug 1317433.

In the metrics store we collect the vm disk stats as rates and not commutative.
It can be aggregated in the kibana by the vm, but only for the range that exists.

Comment 6 Yaniv Lavi 2017-07-06 13:18:01 UTC

(In reply to Shirly Radco from comment #5)
> I don't think there is any update on this.
> It is still dependent on bug 1317433.
> 
> In the metrics store we collect the vm disk stats as rates and not
> commutative.
> It can be aggregated in the kibana by the vm, but only for the range that
> exists.

That is reasonable to me.

Comment 7 Yaniv Lavi 2017-07-31 08:20:54 UTC


*** This bug has been marked as a duplicate of bug 1317433 ***