I think it would be useful to get thoughts on manageiq chargeback component and how to improve it.
Lets start the discussion…
I think it would be useful to get thoughts on manageiq chargeback component and how to improve it.
Lets start the discussion…
Here are some initial thoughts on what I would like to see with Chargeback.
From a hosting perspective, I’d ideally like to see:
It would be nice to source the rates from some automate. In the same way that dynamic Drop downs are configured and operated, we should be able to create a Rate Table called AWS, and have the automate run upon a schedule to collect the latest rates from AWS, or any source for that matter.
Its imperative that multiple rates and types can be applied to a single object, for example. I want a Service to have a whole cost, but also a utilisation cost, but then the VMs within need a Network I/O cost, and lastly if the CPU’s are set above a default level then we get per component charging too. When a chargeback report is created it should compile all together but also show the breakdown too.
Chargeback reports should be supported from a REST call, including there executing and retrieval.
A little off topic but linking ChargeBack to infrastructure costs, we should be able to put a $ price on our infrastructure, this should break down to profile the license cost of the virtulization platform, datacenter costs, cooling, etc…these cost profiles for the infrastructure should be able to be used in conjunction with ChargeBack, furthermore the end goal here would be to enable ManageIQ to show which of the providers it has managed is the cheapest. When doing this we should show both an average cost based on a average vm size across all providers but also a costing that is the average vm on THAT provider. This is because instances on AWS are quite often different to that of VMware, so comparing a standard VM size on AWS is unfair.
I guess what we should get to is the ability for a user to;
thanks
Great discussion - would someone like to summarize it and post as a feature request/enhancement on github issues?
I’d like to echo the comments of jcornell and jhardy. From a service provider perspective these would be great enhancements. From my perspective it would be great to see;
It would be nice for non-Americans to be able to specify a currency symbol other than the ‘$’ sign.
I agree with this. Customers should see rates in their language.
There are some other factors when adding several currencies to a system, like having the ability to hold different rates per currency and aggregate them into a single rate:
https://bugzilla.redhat.com/show_bug.cgi?id=1052106
There should be a way to generate data records (xDR/IPDR/CDR): standard information that a billing system can use to create the bill, with a fixed cadence (each minute/hour/day/whatever), identifying services that have finished, still running, etc.
Ideally: every x time, a CDR per service/vm is generated, aggregated and uploaded to a shared storage so a mediation engine can use it
More ideally: some treatment is done on the CDR so mediation the need for mediation is reduced (some mediation capabilities will add value to the solution as it could generate/aggregate/prepare information from different sources)
Awesome: Diameter CCA is used to report in near-real-time, real-time is supported in the future.
There are two types of rating systems in the market:
We are gathering requirements to create CDR for both systems. I have
information for billing systems, would somebody knows requirements for
ERP-like type?
https://github.com/rhus/charging-docs/wiki/Requirements:-Collection-and-Mediation
Thanks!
This is a basic cloud charging model, ala AWS, which is to charge for the flavor. So instead $x for CPU, $y for RAM and $z for disk, it could just be $xx.yy per month for m1.small. This may already be there but for the likes of me we’ve never been able to make it work in the chargeback module.
Hey @sergio_ocon
In terms of provisioning to the cheapest provider, eg dev or sandbox type workloads. For example the dev wants to just try something quickly. They go the service catalog and orders the vm/instance. Automate then uses a form of cost calculation to decide where to build the vm/instance. Much easier said than done. The dev might be asked to select a vm/instance flavour (cpu, mem, disk) and then miq (automate) normalises it to compare across the providers.
Thanks
There was some preliminary work on this that is there but it is not enabled by default:
Basically it provides a way of generating a JSON with a payload and trigger an API call that will give you the price.
Unfortunately, right now it can be used to substitute the legacy rating, but it does not provide the full capabilities you need, as you can’t define a price plan, it basically generates one on the fly from the old data.
The next step would be to change the price plan management to the new system, so the price plans are completely done and assigned using the new code and tables. With that done, you can basically generate a JSON, call rating on it, and get the estimated price for the payload. If you generate one for every option, you would get your use case fully done.
However, I am no longer working on this. I am dedicating 100% of my time to a new project. Feel free to review the existing code and see if you can improve it.