Chapter 8. Integration of OpenStack components and their relationship with director and the overcloud

Use the following concepts about specific integration points to begin integrating hardware and software with Red Hat OpenStack Platform (RHOSP).

8.1. Bare Metal Provisioning (ironic)

Use the OpenStack Bare Metal Provisioning (ironic) component within director to control the power state of the nodes. Director uses a set of back-end drivers to interface with specific bare metal power controllers. These drivers are the key to enabling hardware and vendor specific extensions and capabilities. The most common driver is the IPMI driver, pxe_ipmitool, which controls the power state for any server that supports the Intelligent Platform Management Interface (IPMI).

Integration with Bare Metal Provisioning starts with the upstream OpenStack community. Ironic drivers accepted upstream are automatically included in the core RHOSP product and director by default. However, they might not be supported according to certification requirements.

Hardware drivers must undergo continuous integration testing to ensure their continued functionality. For more information about third-party driver testing and suitability, see the OpenStack community page Ironic Testing.

Upstream Repositories:

Puppet Module:

Bugzilla components:

  • openstack-ironic
  • python-ironicclient
  • openstack-puppet-modules
  • openstack-tripleo-heat-templates

Integration Notes:

  • The upstream project contains drivers in the ironic/drivers directory.
  • Director performs a bulk registration of nodes defined in a JSON file.
  • Director is automatically configured to use Bare Metal Provisioning, which means the Puppet configuration requires little to no modification. However, if your driver is included with Bare Metal Provisioning, you must add your driver to the /etc/ironic/ironic.yaml file. Edit this file and search for the IronicEnabledHardwareTypes parameter:

    IronicEnabledHardwareTypes=ipmi,redfish,idrac,ilo

    This allows Bare Metal Provisioning to use the specified driver from the drivers directory.

8.2. Networking (neutron)

OpenStack Networking (neutron) provides the ability to create a network architecture within your cloud environment. The project provides several integration points for Software Defined Networking (SDN) vendors. These integration points usually fall into the categories of plugins or agents:

A plugin allows extension and customization of pre-existing neutron functions. Vendors can write plugins to ensure interoperability between neutron and certified software and hardware. Develop a driver for neutron Modular Layer 2 (ml2) plugin, which provides a modular back end for integrating your own drivers.

An agent provides a specific network function. The main neutron server and its plugins communicate with neutron agents. Existing examples include agents for DHCP, Layer 3 support, and bridging support.

For both plugins and agents, you can choose one of the following options:

  • Include them for distribution as part of the Red Hat OpenStack Platform (RHOSP) solution
  • Add them to the overcloud images after RHOSP distribution

Analyze the functionality of existing plugins and agents to determine how to integrate your own certified hardware and software. In particular, it is recommended to first develop a driver as a part of the ml2 plugin.

Upstream Repositories:

Upstream Blueprints:

Puppet Module:

Bugzilla components:

  • openstack-neutron
  • python-neutronclient
  • openstack-puppet-modules
  • openstack-tripleo-heat-templates

Integration Notes:

  • The upstream neutron project contains several integration points:

    • The plugins are located in neutron/plugins/
    • The ml2 plugin drivers are located in neutron/plugins/ml2/drivers/
    • The agents are located in neutron/agents/
  • Since the OpenStack Liberty release, many of the vendor-specific ml2 plugin have been moved into their own repositories beginning with networking-. For example, the Cisco-specific plugins are located in https://github.com/openstack/networking-cisco
  • The puppet-neutron repository also contains separate directories to configure these integration points:

    • The plugin configuration is located in manifests/plugins/
    • The ml2 plugin driver configuration is located in manifests/plugins/ml2/
    • The agent configuration is located in manifests/agents/
  • The puppet-neutron repository contains numerous additional libraries for configuration functions. For example, the neutron_plugin_ml2 library adds a function to add attributes to the ml2 plugin configuration file.

8.3. Block Storage (cinder)

OpenStack Block Storage (cinder) provides an API that interacts with block storage devices, which Red Hat OpenStack Platform (RHOSP) uses to create volumes. For example, Block Storage provides virtual storage devices for instances. Block Storage provides a core set of drivers to support different storage hardware and protocols. For example, some of the core drivers include support for NFS, iSCSI, and Red Hat Ceph Storage. Vendors can include drivers to support additional certified hardware.

Vendors have the following two main options with the drivers and configuration they develop:

  • Include them for distribution as part of the RHOSP solution.
  • Add them to the overcloud images after RHOSP distribution.

Analyze the functionality of existing drivers to determine how to integrate your own certified hardware and software.

Upstream Repositories:

Upstream Blueprints:

Puppet Module:

Bugzilla components:

  • openstack-cinder
  • python-cinderclient
  • openstack-puppet-modules
  • openstack-tripleo-heat-templates

Integration Notes:

  • The upstream cinder repository contains the drivers in cinder/volume/drivers/
  • The puppet-cinder repository contains two main directories for driver configuration:

    • The manifests/backend directory contains a set of defined types that configure the drivers.
    • The manifests/volume directory contains a set of classes to configure a default block storage device.
  • The puppet-cinder repository contains a library called cinder_config to add attributes to the Cinder configuration files.

8.4. Image Storage (glance)

OpenStack Image service (glance) provides an API that interacts with storage types to provide storage for images. Image service provides a core set of drivers to support different storage hardware and protocols. For example, the core drivers include support for file, OpenStack Object Storage (swift), OpenStack Block Storage (cinder), and Red Hat Ceph Storage. Vendors can include drivers to support additional certified hardware.

Upstream Repositories:

Upstream Blueprints:

Puppet Module:

Bugzilla components:

  • openstack-glance
  • python-glanceclient
  • openstack-puppet-modules
  • openstack-tripleo-heat-templates

Integration Notes:

  • Adding a vendor-specific driver is not necessary because Image service can use Block Storage, which contains integration points, to manage image storage.
  • The upstream glance_store repository contains the drivers in glance_store/_drivers.
  • The puppet-glance repository contains the driver configuration in the manifests/backend directory.
  • The puppet-glance repository contains a library called glance_api_config to add attributes to the Glance configuration files.

8.5. Shared File Systems (manila)

OpenStack Shared File Systems service (manila) provides an API for shared and distributed file system services. Vendors can include drivers to support additional certified hardware.

Upstream Repositories:

Upstream Blueprints:

Puppet Module:

Bugzilla components:

  • openstack-manila
  • python-manilaclient
  • openstack-puppet-modules
  • openstack-tripleo-heat-templates

Integration Notes:s

  • The upstream manila repository contains the drivers in manila/share/drivers/.
  • The puppet-manila repository contains the driver configuration in the manifests/backend directory.
  • The puppet-manila repository contains a library called manila_config to add attributes to the manila configuration files.

8.6. OpenShift-on-OpenStack

Red Hat OpenStack Platform (RHOSP) aims to support OpenShift-on-OpenStack deployments. For more information about the partner integration for these deployments, see the Red Hat OpenShift Partners page.