Chargeback Open Discussion


#1

I think it would be useful to get thoughts on manageiq chargeback component and how to improve it.

Lets start the discussion…


#2

Here are some initial thoughts on what I would like to see with Chargeback.

  • Cost profiles that can be linked/tagged to different Cloud or Infrastructure Providers, Clusters, Availability Zones etc.
  • Ability to charge a fixed price for a catalog item based on the specifications (CPU, Memory, Disk) selected at time of ordering. This would be linked to the cost profile which defines x$ per vCPU, y$ GB of Mem, z$ GB of storage.
  • Project, Department, budget code management. The ability to manage these within the Chargeback area in MIQ and ideally pull them in from external sources to support enterprises with other systems of record for these attributes.
  • Integration with 3rd party cost management solutions such as Cloudyn and Cloudability for the public cloud chargeback integration.
  • The ability to create a service catalog with various options for deployment ie. VMWare OnPrem vs AWS vs OpenStack. Would allow the end user to see the comparison of pricing from the Chargeback features of the environments they are able to provision against and be able to select the one that meets their needs.

#3

From a hosting perspective, I’d ideally like to see:

  • The ability to have two rates: cost to
    provide the service and price to charge the customer.
  • Ability to dynamically change the rates based upon consumption of services.

#4

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;

  1. See how much their clouds are costing them NOW
  2. See how much their clouds COULD cost by profiling different workloads.
  3. Be able in automate gain access to all the charging and costing data to be able to fork, example that we could stop a provision if the budget is blown, or provisioning else where because a cheaper cloud is now available that matches workload needs.

thanks


#5

Great discussion - would someone like to summarize it and post as a feature request/enhancement on github issues?


#6
  • as a regular user, generate chargeback report based on tags and not for user ownership only.

#7

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;

  • Automating input prices from cloud providers (AWS)
  • Setting a “cost” and a “sell” price for each catalog item (ie: multiple rates per item)
  • The ability to define a cost against service catalog entries, stretching into cloud, VMware based, and physical environments, even if CloudForms is just being used as a basic way of passing input variables to an external orchestration platform (puppet for example)
  • The ability to multi-tenant chargeback in a more granular way, so that individual customers can create a charge back report based on their tagged assets, and then report at a wider organizational level (ie: a cusotmer_admin can report against all assets tagged to that company, but not another company on the platform).

#8

It would be nice for non-Americans to be able to specify a currency symbol other than the ‘$’ sign.


#9

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


#10

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.


#12

There are two types of rating systems in the market:

  • Billing systems. They get information from external parties, deduplicate
    it, aggregate and rate them. For instance, telco billing is build this
    way (millions of call data records per day are processed)
  • ERP-like
    billing. Aggregates are calculated externally prior to rating. So the
    information they use for rating is already aggregated.

We are gathering requirements to create CDR for both systems. I have
information for billing systems, would somebody knows requirements for
ERP-like type?

Thanks!


#13

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.


#14

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


#15

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.