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 v2 (deprecated)¶

[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

[auth]
username = cloudkitty
password = CK_PASSWORD
tenant = service
region = RegionOne
url = http://KEYSTONE_HOST:5000/v2.0

[keystone_authtoken]
username = cloudkitty
password = CK_PASSWORD
project_name = service
region = RegionOne
auth_url = http://KEYSTONE_HOST:5000/v2.0
auth_plugin = password

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

[storage]
backend = sqlalchemy

[keystone_fetcher]
username = cloudkitty
password = CK_PASSWORD
tenant = service
region = RegionOne
url = http://KEYSTONE_HOST:5000/v2.0

[collect]
collector = ceilometer
period = 3600
services = compute, volume, network.bw.in, network.bw.out, network.floating, image

[ceilometer_collector]
username = cloudkitty
password = CK_PASSWORD
tenant = service
region = RegionOne
url = http://KEYSTONE_HOST:5000/v2.0

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:35357/
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://CK_DBUSER:CK_DBPASSWORD@DB_HOST/cloudkitty

[keystone_fetcher]
auth_section = ks_auth
keystone_version = 3

[tenant_fetcher]
backend = keystone

It is now time to configure the storage backend. Four storage backends are available: sqlalchemy, hybrid, gnocchihybrid, and gnocchi.

[storage]
backend = gnocchi

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

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

[storage_gnocchi]
auth_section = ks_auth

Three collectors are available: Ceilometer (deprecated, see the Telemetry documentation), 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

[gnocchi_collector]
auth_section = ks_auth

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

- name: OpenStack

  collector: gnocchi
  period: 3600
  wait_periods: 2
  window: 1800

  services:
    - compute
    - volume
    - network.bw.in
    - network.bw.out
    - network.floating
    - image

  services_objects:
    compute: instance
    volume: volume
    network.bw.out: instance_network_interface
    network.bw.in: instance_network_interface
    network.floating: network
    image: image
    radosgw.usage: ceph_account

  services_metrics:
    compute:
      - vcpus: max
      - memory: max
      - cpu: max
      - disk.root.size: max
      - disk.ephemeral.size: max
    volume:
      - volume.size: max
    network.bw.in:
      - network.incoming.bytes: max
    network.bw.out:
      - network.outgoing.bytes: max
    network.floating:
      - ip.floating: max
    image:
      - image.size: max
      - image.download: max
      - image.serve: max
    radosgw.usage:
      - radosgw.objects.size: max

  metrics_units:
    compute:
      1:
        unit: instance
    volume:
      volume.size:
        unit: GiB
    network.bw.in:
      network.incoming.bytes:
        unit: MB
        factor: 1/1000000
    network.bw.out:
      network.outgoing.bytes:
        unit: MB
        factor: 1/1000000
    network.floating:
      1:
        unit: ip
    image:
      image.size:
        unit: MiB
        factor: 1/1048576
    radosgw.usage:
      radosgw.objects.size:
        unit: GiB
        factor: 1/1073741824
    default_unit:
      1:
        unit: unknown

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