# Step by step configuration guide

Note

For a sample `cloudkitty.conf` file, see cloudkitty.conf reference .

Edit `/etc/cloudkitty/cloudkitty.conf` to configure cloudkitty.

## Common options

Options supported by most OpenStack projects are also supported by cloudkitty:

    [DEFAULT]
    verbose = true
    debug = false
    log_dir = /var/log/cloudkitty
    transport_url = rabbit://RABBIT_USER:RABBIT_PASSWORD@RABBIT_HOST

## API authentication method

The authentication method is defined through the `auth_strategy` option in the `[DEFAULT]` section.

### Standalone mode

If you’re using CloudKitty in standalone mode, you’ll have to use noauth:

    [DEFAULT]
    auth_strategy = noauth

### Keystone integration

If you’re using CloudKitty with OpenStack, you’ll want to use Keystone authentication:

    [DEFAULT]
    auth_strategy = keystone

When using Keystone, you’ll have to provide the CloudKitty credentials for Keystone. These must be specified in the `[keystone_authtoken]` section. Since these credentials will be used in multiple places, it is convenient to use a common section:

    [ks_auth]
    auth_type = v3password
    auth_protocol = http
    auth_url = http://KEYSTONE_HOST:5000/
    identity_uri = http://KEYSTONE_HOST:5000/
    username = cloudkitty
    password = CK_PASSWORD
    project_name = service
    user_domain_name = default
    project_domain_name = default

    [keystone_authtoken]
    auth_section = ks_auth

Note

The `service` project may also be called `services`.

CloudKitty provides the `rating` OpenStack service.

To integrate cloudkitty to Keystone, run the following commands (as OpenStack administrator):

    openstack user create cloudkitty --password CK_PASSWORD

    openstack role add --project service --user cloudkitty admin

    openstack service create rating --name cloudkitty \
        --description "OpenStack Rating Service"

    openstack endpoint create rating --region RegionOne \
        public http://localhost:8889

    openstack endpoint create rating --region RegionOne \
        admin http://localhost:8889

    openstack endpoint create rating --region RegionOne \
        internal http://localhost:8889

## Storage

The next step is to configure the storage. Start with the SQL and create the `cloudkitty` table and user:

    mysql -uroot -p << EOF
    CREATE DATABASE cloudkitty;
    GRANT ALL PRIVILEGES ON cloudkitty.* TO 'CK_DBUSER'@'localhost' IDENTIFIED BY 'CK_DBPASSWORD';
    EOF

Specify the SQL credentials in the `[database]` section of the configuration file:

    [database]
    connection = mysql+pymysql://CK_DBUSER:CK_DBPASSWORD@DB_HOST/cloudkitty

Once you have set up the SQL database service, the storage backend for rated data can be configured. A complete configuration reference can be found in the storage backend configuration guide. We’ll use a v2 storage backend, which enables the v2 API. The storage version and driver to use must be specified in the `[storage]` section of the documentation:

    [storage]
    version = 2
    backend = influxdb

Driver-specific options are then specified in the `[storage_{drivername}]` section:

    [storage_influxdb]
    username = cloudkitty
    password = cloudkitty
    database = cloudkitty
    host = influxdb

Once you have configured the SQL and rated data storage backends, initalize the storage:

    cloudkitty-storage-init

Then, run the database migrations:

    cloudkitty-dbsync upgrade

## Fetcher

The fetcher retrieves the list of scopes to rate, which will then be passed to the collector. A complete configuration reference can be found in the fetcher configuration guide. For this example, we’ll use the `gnocchi` fetcher, which will discover scopes (in this case OpenStack projects) to rate. The fetcher to use is specified through the `backend` option of the `[fetcher]` section:

    [fetcher]
    backend = gnocchi

Fetcher-specific options are then specified in the `[fetcher_{fetchername}]` section:

    [fetcher_gnocchi]
    auth_section = ks_auth
    region_name = MyRegion

## Collector

The collector will retrieve data for the scopes provided by the fetcher and pass them to the rating modules. The collector to use is specified in the `[collect]` section, and the collector-specific options are specified in the `[collector_{collectorname}]` section:

    [collect]
    collector = gnocchi

    [collector_gnocchi]
    auth_section = ks_auth
    region_name = MyRegion

Note that you’ll also have to configure what metrics the collector should collect, and how they should be collected. Have a look at the collector configuration guide for this:

## Orchestrator

The orchestrator section enables CloudKitty operators to configure general settings such as coordination_url, max_workers, max_workers_reprocessing, max_threads, and skip_datapoints_expression.

### skip_datapoints_expression

This option allows operators to write Python expression that can be used to skip/ignore the processed datapoint from being persisted in the storage backend. This is useful to avoid persisting entries in the storage backend when the QTY is zero, for instance. The datapoint being persisted will be available for the expression in a variable called “datapoint”. The expression MUST return a True or False value. For instance, if one wants to skip persisting processed datapoints that have qty as zero, the following expression can be used:

    "datapoint.get(\"vol\", {}).get(\"qty\", 0) == 0"

The available objects to be used in the expressions are the following:

> - datapoint: it represents the datapoint used in the rating process. The datapoint has fields such as qty and price that can be used. The price fields is located under rating attribute (it is a dictionary), and the qty field is located under vol attribute (it is a dictionary). The groupby attribute represents all of the group-by attributes (it is a dictionary) and their respective values. The metadata attribute represents all of the metadata attributes (it is a dictionary) and their respective values.

> - excluded_datapoints: it is a list with all of the datapoints already filtered out.

> - filtered_datapoints: a list with the datapoints that will be persisted.

> - skip_datapoint_expression: the expression used to decided if we need or not to exclude the datapoint.

> - usage_data_metric_name: the metric name being processed.

this page last updated: 2026-08-16 04:39:41

Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.

found an error? report a bug