Jump to: navigation, search

Difference between revisions of "CloudKitty"

Line 17: Line 17:
 
* output file format
 
* output file format
  
CloudKitty supports multiple collectors, multiple policies and multiple outputs.
+
CloudKitty supports multiple collectors, multiple rating policies and multiple outputs.
  
 
== How to use it ? ==
 
== How to use it ? ==

Revision as of 13:45, 11 November 2014

CloudKitty

CloudKitty is the project name of a PricingAsAService project started.

Motivation

From the beginning of the Ceilometer project billing and pricing where excluded of the goals to acheive. But since aspects those are inherent to providing cloud (for both public and/or private), this gap needed to be filled using both the same technologies and the same Open Source approach than the rest of OpenStack project. That is the goal of CloudKitty which is so far developped by Objectif Libre, but we are really hoping to get more developpers on board on a next future.

The project has been started before the Atlanta's Summit, and a prototype has been shown to few people (mainly from the Ceilometer project), that all gave us great feedback and interest on the project.

We know that billing is made of generic rules, but also some specific ones. Our approach is to be modular allowing every treatment. We will focus on many generic rules, but allowing specific cases to be ruled by specific modules.

CloudKitty has been made to be highly modular at 4 levels :

  • input data sources (collectors)
  • rating policies (rating pipeline)
  • output storage (storage)
  • output file format

CloudKitty supports multiple collectors, multiple rating policies and multiple outputs.

How to use it ?

CloudKitty proposes the following way to interact with it :

  • Horizon
  • API
  • Python Binding


Architecture

Cloudkitty relies heavily on Ceilometer, but some other components of OpenStack (or classical components of OpenStack) are also used :

  • oslo.db
  • oslo.config
  • pecan
  • WSME
  • stevedore

Licencing

CloudKitty is realeased under Apache 2.0 Licence.

Current Implementation

The project is under high work in progress, but the basis or the architecture are already present including the dynamic modular architecture that allows to enable/disable modules (and thus capabilities / treatment) on the fly. So far the architecture is signle-user, but the multi-user / multi-tenant is started on our local development branch.

Current Collectors

So far only the compute collector has been (partly) implemented since we need a test case. It is something that will be expanded on the next weeks.

Current REST API

The API is still evolving for now, but here what exists:

  • GET /v1/billing/modules: List all the modules available
  • GET /v1/billing/modules/<module_name>: Get the list of the services associated to that module
  • GET /v1/report/total: Get the total price of the current period
  • POST /v1/billing/quote: Take a JSON with many ressource parameter and get the expected price of that ressource for the configured period

Current Horizon Integration

The horizon integration falls in 2 parts :

  • administration
  • user

Administration View

Using the administration pane, it is possibile to activate / desactivate services. It is also possible to pass values to configure the various services.

To get an idea of the horizon integration for the administrators we have published a video that shows the management of the price for ressources by an admin: https://www.youtube.com/watch?v=KlagCqTUPco

User View

It is of course the displaying "real-time" (the granularity is defined in the administration panel) price.

To get an idea of the horizon integration for users we have published a video that shows the user part of cloudkitty :

 * How the user will see the estimated price of the ressource they are about to launch  https://www.youtube.com/watch?v=CmaBXzv28oI
 * How the user see the total price he will be charged for his past usage https://www.youtube.com/watch?v=v6m1vPl55pg


RoadMap

Some aspects are moving very fast, here is the content of our RoadMap

General Architecture

The main change will be to enable the multi-user / multi-tenant.This work is already in progress. Since we want to spread the project, it is important to enable translation in the various aspect of CloudKitty.

RoadMap of the Collectors

It is one of the big work we are envisaging : covering all ressources... that includes :

  • Pricing associated to images (Glance)
  • Pricing associated to network (Neutron)
  • Pricing associated to volumes (cinder)
  • Improvment to compute informations

Some of that elements will be treated using events emited by the various components.

RoadMap of the REST API

The roadmap here is focussing on the API of each new module.

RoadMap of the Horizon Integration

The roadmap here is focussing on configuring each new module using Horizon.

Documentation

We have an automated generated documentation (extracted from the code) available at

http://cloudkitty.readthedocs.org/en/latest/


Community

StackForge

IRC

#cloudkity on freenode