Author:Michal Giertych, Lukasz Dolata

OpenStack is one of most popular open source softwares for building scalable cloud infrastructures. This tool has a highly modular architecture that controls variaty of resources including compute, network and storage. Each of the management or control component can be replaced by custom implementation. All of them exposes their own APIs and may comunicate with other components in three different ways through: API, message queues and databases. This flexibility and decentralized architecture has caused that currently there are number of specialized modules on the market for management of miscellaneous hardware and configurations in the data centers.


Figure: Site Example using OpenStack and its components

The BonFIRE site should consist of at least: Nova, Keystone, Glance but due to limitation it is recommended to extend this list of component with Quantum and Cinder for managing and customization of networking and volumes.

Enactor Adaptor (experimental)

As OpenStack software exposes several kind of APIs and can be also accessible through third party solutions build on top of it. These are examples of exposed interfaces: direct API of each component, Amazon EC2 or OCCI server. The Enactor adaptor for OpenStack uses the first approach and handles communication through the following libraries:


This EndPoint communicates directly with OpenStack modules: Keystone, Nova and Quantum. As it is stateless plugin it is necessary to pass the same requests and retrieve the same data from OpenStack very often. For example whenever the adaptor is called it has to authorize in OpenStack Keystone to get auth token. Caching mechanism would solve the problem of additional communication between Enactor and site.


Figure: OpenStack Endpoint

API provided

The current implementation of the adaptor offers basic functionality:

  • list of available configurations
  • Compute: retrieve, create, delete
  • Network: retrieve
  • Storage: retrieve
  1. Configurations
curl -v --header x_bonfire_asserted_id:{USER_ID} {ENACTOR_URL}/locations/{location_id}/configurations
  1. Computes
  • create
curl -v -H 'X-Bonfire-Asserted-Id: {USER_ID}' -H 'X-Bonfire-Asserted-Groups: {LIST_OF_GOUPS}' -H 'X-Bonfire-Experiment-Id: {EXPERIMENT_ID}' -X POST -d '
<compute xmlns="">
  • retrieve information
curl -v --header x_bonfire_asserted_id:{USER_ID} {ENACTOR_URL}/locations/{location_id}/computes/{COMPUTE_ID}
  • delete
curl -v --header x_bonfire_asserted_id:{USER_ID} {ENACTOR_URL}/locations/{location_id}/computes/{COMPUTE_ID} -X POST
  1. Networks

List of available networks for user:

curl -v --header x_bonfire_asserted_id:{USER_ID} {ENACTOR_URL}/locations/{location_id}/networks
  1. Storages

List of available storage (images) for user:

curl -v --header x_bonfire_asserted_id:{USER_ID} {ENACTOR_URL}/locations/{location_id}/storages


OpenStack provides contextualization mechanism using Metadata Service over the network. The following Workflow explains how the user parameters are passed to launched computes:

  1. User creates VM and provides the key/value metadata or user-data which are assigned to this particular compute in Metadata Service
  2. VM configures network interfaces through DHCP so the VM has access to the local network at the boot time.
  3. When networking is up it is possible to run e.g. cloud-init service or any other custom scripts to retrieve metadata infromation through special url: . At this private address Metadata Service exposes parameters and any other user-data provided in the first step.
  • currently Metadata Service offers two formats: EC2 compatible and OpenStack
  1. Current Bonfire images use OpenNebula compatible scripts that are mounted as iso type device and executed. To provide compatibility with existing soultion image has to download clean context scripts at boot time, mount and inject metadata parameters to ‘’ file before contextualization scripts are executed.

List of known issues, bugs and workarounds:

  1. OpenStack (Grizzly) can handle metadata with keys and values sizes <255 bytes. It is not suitable to carry all BonFIRE context parameters (e.g. “AUTHORIZED_KEYS” with one and more keys exceeding 255 bytes limit). There is one workaround to pass all context params through ‘user_data’, but they cannot be read from API. See:
  2. Passing AUTHORIZED can be passed to VM in 3 ways:
  • using “user_data” block
  • through Personality files that are injected to VM at specified path (used by cloud-init package).
  • by creating or using existing Keypairs feature. However this is intend to by used for single ssh key but it should not be limited.
  1. OpenStack does not support customization of context parameters at testbed level to provide dynamic values. However for Image and Flavors there is some metadata support.

Table Of Contents

Previous topic

Wellness OCCI

Next topic

Monitoring Core

This Page