Chapter 1. Introduction

The Red Hat OpenStack Platform Director is a toolset for installing and managing a complete OpenStack environment. It is based primarily on the upstream TripleO (OpenStack-on-OpenStack) project. The Director’s primary objective is to fully orchestrate a functional, Enterprise-grade OpenStack deployment with minimal manual configuration. It helps address many of the issues inherent in manually configuring individual OpenStack components.

The end-result OpenStack deployment provided by the Director is called the Overcloud. The Overcloud houses all the components that provide services to end users, including Block Storage. This document provides guidance on how to deploy custom back ends to the Overcloud’s Block Storage service.

This document presumes existing knowledge of concepts relating to manual Block Storage configuration. In a test deployment of OpenStack (for example, through Packstack), configuring this service involves editing its host node’s /etc/cinder/cinder.conf. Most of the Block Storage settings in that file are documented in better detail elsewhere; this document describes how to apply those same settings to the Overcloud in order to attach a custom back end.


This procedure has been tested successfully in limited use cases. Ensure that you test your planned deployment on a non-production environment first. If you have any questions, contact Red Hat support.

1.1. Custom Back Ends

For the purposes of this document, a custom back end is defined as a storage server/appliance or configuration that has yet to be integrated fully into the Red Hat OpenStack Platform Director. Some supported Block Storage back ends are already integrated into the Director; this means that pre-configured Director files are already provided out-of-the-box. An integrated back end can be configured and deployed to the Overcloud through these files. Examples of integrated back ends include Red Hat Ceph and single-back end configurations of Dell EMC PS Series, Dell Storage Center, and NetApp appliances.

Further, some storage appliances already integrated into Director only support a single-instance back end. For example, the pre-configured Director files for Dell Storage Center only allow for the deployment of a single back end. Deploying multiple back end instances of this appliance requires a custom configuration, as demonstrated in this document.

While you can manually configure the Block Storage service by directly editing its node’s /etc/cinder/cinder.conf, the Director will overwrite your configuration once you run openstack overcloud deploy (as you do later on in Chapter 4, Deploy the Configured Back Ends). As such, the recommended method for deploying a Block Storage back end is through the Director, as doing so will ensure that your settings persist through Overcloud deployments and updates.

If a back end configuration is already fully integrated, you can simply edit and invoke its packaged environment files. With custom back ends, however, you need to write your own environment file. This document includes an annotated sample that you can edit for your own deployment, namely /home/stack/templates/custom-env.yaml. This sample file is suitable for configuring the Block Storage service to use two NetApp back ends.

1.2. Requirements

Other than prior knowledge on manually configuring Block Storage and the back end you want to deploy, this document also assumes that:

  • If you are using third-party back end appliances, then they must already be properly configured as storage repositories.
  • The Overcloud has already been deployed through Director, per instructions in Director Installation and Usage.
  • You have the username and password of an account with elevated privileges. You can use the same account that was created to deploy the Overcloud; in Creating a Director Installation User, the stack user is created for this purpose.
  • You have already mapped out the resulting configuration you want for the Block Storage back end in /etc/cinder/cinder.conf. With this, all that remains is the orchestration of your planned configuration through the Director.