Configuration Guide¶

Without authentication¶

If wanted, you can choose to not set any authentication method. This should be set in the DEFAULT block of the configuration file owing to the auth_strategy field:

[DEFAULT]
verbose = True
log_dir = /var/log/cloudkitty
# oslo_messaging_rabbit is deprecated
transport_url = rabbit://RABBIT_USER:RABBIT_PASSWORD@RABBIT_HOST
auth_strategy = noauth

Otherwise, the only other officially implemented authentication method is keystone. More methods will be implemented soon. It should be set in the DEFAULT configuration block too, with the auth_stategy field.

For keystone (identity) API v3¶

The following shows the basic configuration items:

[DEFAULT]
verbose = True
log_dir = /var/log/cloudkitty
# oslo_messaging_rabbit is deprecated
transport_url = rabbit://RABBIT_USER:RABBIT_PASSWORD@RABBIT_HOST/
auth_strategy = keystone

[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
debug = True

[keystone_authtoken]
auth_section = ks_auth

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

[fetcher_keystone]
auth_section = ks_auth
keystone_version = 3

[tenant_fetcher]
backend = keystone

It is now time to configure the storage backend. Two storage backends are available: sqlalchemy and hybrid (SQLalchemy being the recommended one).

[storage]
backend = sqlalchemy
version = 1

As you will see in the following example, collector and storage backends sometimes need additional configuration sections. (The tenant fetcher works the same way). The section’s name has the following format: {backend_type}_{backend_name} (collector_gnocchi for example).

If you want to use the hybrid storage with a gnocchi backend, add the following entry:

[storage_gnocchi]
auth_section = ks_auth

Two collectors are available: Gnocchi and Monasca. The Monasca collector collects metrics published by the Ceilometer agent to Monasca using Ceilosca.

The collect information, is separated from the Cloudkitty configuration file, in a yaml one.

This allows Cloudkitty users to change metrology configuration, without modifying source code or Cloudkitty configuration file.

[collect]
metrics_conf = /etc/cloudkitty/metrics.yml

[collector_gnocchi]
auth_section = ks_auth

The /etc/cloudkitty/metrics.yml file looks like this:

metrics:
  cpu:
    unit: instance
    alt_name: instance
    groupby:
      - id
      - user_id
      - project_id
    metadata:
      - flavor_name
      - flavor_id
      - vcpus
    mutate: NUMBOOL
    extra_args:
      aggregation_method: mean
      resource_type: instance

  image.size:
    unit: MiB
    factor: 1/1048576
    groupby:
      - id
      - user_id
      - project_id
    metadata:
      - container_format
      - disk_format
    extra_args:
      aggregation_method: mean
      resource_type: image

  volume.size:
    unit: GiB
    groupby:
      - id
      - user_id
      - project_id
    metadata:
      - volume_type
    extra_args:
      aggregation_method: mean
      resource_type: volume

  network.outgoing.bytes.rate:
    unit: MB
    groupby:
      - id
      - project_id
      - user_id
    # Converting B/s to MB/h
    factor: 3600/1000000
    metadata:
      - instance_id
    extra_args:
      aggregation_method: mean
      resource_type: instance_network_interface

  network.incoming.bytes.rate:
    unit: MB
    groupby:
      - id
      - project_id
      - user_id
    # Converting B/s to MB/h
    factor: 3600/1000000
    metadata:
      - instance_id
    extra_args:
      aggregation_method: mean
      resource_type: instance_network_interface

  ip.floating:
    unit: ip
    groupby:
      - id
      - user_id
      - project_id
    metadata:
      - state
    mutate: NUMBOOL
    extra_args:
      aggregation_method: mean
      resource_type: network

  radosgw.objects.size:
    unit: GiB
    groupby:
      - id
      - user_id
      - project_id
    factor: 1/1073741824
    extra_args:
      aggregation_method: mean
      resource_type: ceph_account

Conversion information is included in the yaml file. It allows operators to change metrics units for rating and so to not stay stuck with the original unit.

The conversion information must be set for each metric. It includes optionals factor and offset, plus a mandatory final unit (used once the conversion is done). By default, factor and offset are 1 and 0 respectively. All type of linear conversions are so covered. The complete formula looks like:

new_value = (value * factor) + offset

Setup the database and storage backend¶

MySQL/MariaDB is the recommended database engine. To setup the database, use the mysql client:

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

If you need to authorize the mysql user associated to cloudkitty from another host you have to change the line accordingly.

Run the database synchronisation scripts:

cloudkitty-dbsync upgrade

Init the storage backend:

cloudkitty-storage-init

Integration with Keystone¶

cloudkitty uses Keystone for authentication, and provides a rating service.

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

openstack user create cloudkitty --password CK_PASSWORD \
    --email cloudkitty@localhost
openstack role add --project service --user cloudkitty admin

Give the rating role to cloudkitty for each project that should be handled by cloudkitty:

openstack role create rating
openstack role add --project XXX --user cloudkitty rating

Create the rating service and its endpoints:

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

If you installed cloudkitty from packages¶

Start the processing services:

systemctl start cloudkitty-processor.service

If you installed cloudkitty from sources¶

Start the processing services:

cloudkitty-processor --config-file /etc/cloudkitty/cloudkitty.conf

Choose and start the API server¶

Cloudkitty includes the cloudkitty-api command. It can be used to run the API server. For smaller or proof-of-concept installations this is a reasonable choice. For larger installations it is strongly recommended to install the API server in a WSGI host such as mod_wsgi (see Installing the API behind mod_wsgi). Doing so will provide better performance and more options for making adjustments specific to the installation environment.

If you are using the cloudkitty-api command it can be started as:

$ cloudkitty-api -p 8889