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