Configuring CORS for Gnocchi and Keystone

/!\ Since mitaka, this article is obsolete, see Gnocchi documentation for updated information /!\

In some case Cross-origin resource sharing (CORS) is required on some REST API to work with certain applications.

For example, if you want to use Grafana with the Gnocchi datasource, some setup are required on the Gnocchi and Keystone side to allow grafana UI to access to Gnocchi REST API.

All of this configuration have can be done easly since Liberty version of Openstack and was not yet supported in previous version (at least in this way).

Since Liberty, we can use the oslo.middleware CORS middleware without waiting it’s CORS integration into a Openstack application. In mitaka, Keystone and Gnocchi got CORS integration out of the box and the following modifications are no more needed.

Note that on my example, my Grafana server is http://my-grafana-ipdomain:3000.

On Keystone side

Add a new filter to the ...

Read More

Autoscaling with Heat, Ceilometer and Gnocchi

A while ago, I had made a quick article/demo of how to use Ceilometer instead of the built-in emulated Amazon CloudWatch resources of Heat.

To extend on the previous post, when you create a stack, instances of the stack generated notifications that were received by Ceilometer and converted into samples to be written to a database; usually MongoDB. On the other end, Heat created some alarms using the Ceilometer API to trigger the Heat autoscaling actions. These alarms defined some rules against statistics based on the previously recorded samples. These statistics were computed on the fly when the alarms were evaluated.

The main issue with this setup was that the performance for evaluating all the defined alarms was directly tied to the number of alarms and to the complexity of computing the statistics. The computation of a statistic would result in a map reduce in MongoDB. Therefore, when there ...

Read More

Writing a Gnocchi storage driver for ceph

As presented by Julien Danjou, Gnocchi is designed to store metric metadata into an indexer (usually a SQL database) and store the metric measurements into another backend. The default backend creates timeseries using Carbonara (a pandas based library) and stores them into Swift.

The storage Gnocchi backend is pluggable, and not all deployments install Swift, so I have decided to write another backend, I have chosen Ceph because it’s close to Swift in the way we use it in Gnocchi and scale well when we have many objects stored too. Now, let’s see what I need to do to reach this goal.

Storage driver interface

The current metric storage driver interface to implement looks like this:

  • create_metric(metric, archive_policy)
  • add_measures(metric, measures)
  • get_measures(metric, from_timestamp=None, to_timestamp=None, aggregation=’mean’)
  • delete_metric(metric)
  • get_cross_metric_measures(metrics, from_timestamp=None, to_timestamp=None, aggregation=’mean’, needed_overlap=None)

Cool, not so many methods to ...

Read More

Autoscaling with Heat and Ceilometer

Like AWS CloudFormation, Heat allows to create auto scaling stacks. In order to do this, some metrics need to be retrieved from your VM and some actions need to be triggered when a specified event occurs on these metrics. These actions are usually upscaling (create some new VMs) or downscaling (destroy some VMs).

In OpenStack Grizzly, a simplistic system was put in place that could mostly serve demonstration needs but could not be used for most real world scenarios: the metrics were retrieved via an agent running inside each VM associated to the Auto Scaling group, and were stored in the Heat database. And the alarms that are triggered up/down auto scaling were stored in the Heat database too.

Thinking about it, it seemed clear that Heat should be a tool which only does orchestration on different API, not storing/handling alarms and metrics, under the UNIX old principle ...

Read More

Using a sharding/replicaSet mongodb with ceilometer

Ceilometer aims to deliver a unique point of contact to acquire all samples across all OpenStack components.

The most commonly used backend is mongodb, this is the only one which implements all ceilometer features.

Due to its nature, collecting many samples from multiple sources, the ceilometer database grows quickly.
For havana, to handle this we have:

I will focus on the second part with an example of mongodb architecture/setup to distribute the ceilometer data into different servers with two replicats of the data.

My setup

Hards:

  • Three servers for the mongodb config servers and mongos routing servers (mongos[1,3])
  • Four servers for the mongodb data servers (two shard with two replicaset) (mongod[1,4])

Softs:

  • Ubuntu Precise
  • Openstack havana-3
  • Mongodb 2.4 (from 10gen repository)

Openstack is installed on ...

Read More