Red Hat OpenStack Platform Director Life Cycle

Deployment tool support policy

Starting on June 27, 2018, Red Hat OpenStack Platform director is the required deployment tool for every new installation of Red Hat OpenStack Platform to receive full support for a Red Hat OpenStack Platform environment.

This policy does not apply retroactively to existing deployments.

In case of any queries with regards to alternative deployment tools usage please contact Red Hat Support.

Overview

Red Hat OpenStack Platform director is:

• Tied to the core Red Hat OpenStack Platform release schedule
• Supported for the same time as the core Red Hat OpenStack Platform product
• Backwards compatible with one previous Red Hat OpenStack Platform core version

What is Red Hat OpenStack Platform director?

Red Hat OpenStack Platform director is a tool used to install and manage the deployment and life cycle of Red Hat OpenStack Platform 7 and later versions. It's targeted specifically for cloud operator use cases where updates, upgrades and infrastructure control are critical for underlying OpenStack operations. It also provides an API driven framework providing hardware introspection, service allocation and management of the OpenStack Platform stack.

For the purposes of this document, we'll split Red Hat OpenStack Platform in two:

• Core: The main OpenStack components (Nova, Neutron, Ironic, etc)
• Director: The deployment management tool

For more information about Red Hat OpenStack Platform installers, read Installing and Managing Red Hat OpenStack Platform.

Release Timing

Red Hat OpenStack Platform director is based on the upstream TripleO project and schedule and is tied to the core product release schedule.

Red Hat OpenStack Platform director is released together with core Red Hat OpenStack Platform.

What will be included in major and maintenance releases?

Major Releases

A major release of director will be available at every major release of core, and is the officially supported way of deploying Red Hat OpenStack Platform. These major releases add features that might have bigger impact on the way Red Hat OpenStack Platform is deployed and will highlight the latest capabilities from core. New major versions might introduce different APIs, which will be documented at release time.

Each director version allows automated in-place upgrades between consecutive major releases of Red Hat OpenStack Platform (for example director version 9 will be able to upgrade the latest core version 8 to the latest version of 9).

Maintenance releases

Maintenance releases occur after the General Availability (GA) of the product and they provide bug fixes and performance improvements. These releases avoid adding new functionality (exceptions will be handled on a case by case basis). This also means that the possibility of API breakage is reduced, as well as the need for DB migrations and other major changes.

Each director version allows automated minor in-place updates between maintenance releases to get the latest content. These updates are handled by a “rolling” procedure - while being in high availability mode, all OpenStack services continue to run.

Life cycle Support

Red Hat OpenStack director has aligned life cycle support with the core product.

For more details please refer to Red Hat OpenStack Platform support. ⁽¹⁾

Integration with other products

Products that want to integrate with director should target their features on major release APIs. The APIs are the standard OpenStack ones: nova, ironic, etc, there aren't any private APIs on director. API versioning and deprecation will follow upstream OpenStack policies ⁽²⁾ plus any backports we decide to carry. These will be explained in the release notes.

Since both director and core will be released at the same time, there shouldn't be many questions regarding timing.

One example of such integration is Cloudforms, which will use the APIs mentioned above to allow for infrastructure management from it. Since they are using the regular APIs the integration should run smoothly and the development cycles can remain decoupled.

^{(2) http://developer.openstack.org/api-ref.html}

Interchanging Deployment and Management Tools

The main use case for director is to do Day 1 (initial deploy) and Day 2 (upgrades, scale up, etc) management. If you want to use Director for Day 2 management, everything needs to be done through Director or using Director APIs. There is no reasonable way for Red Hat to reconcile manual changes made outside of Director, and without that reconciliation, the ability to do scale up, updates or upgrades are completely lost through our supported toolset (Director).

If you choose to use Director for ONLY Day 1 (initial deploy) and do Day 2 management via some other means, you lose Director’s ability to perform any Day 2 operations. Once any tools outside of Director are used, any other operations since then need to be manually orchestrated for things like change management, scale up, updates and upgrades. Manual approach can follow how these orchestrations are implemented in Director to inform of best practices to do it on your own, but the scripts/tools that you use to do this are self-supported (or consulting supported).

Integration with third party tools which are calling Director APIs is supported and does not break Day 2 operations supportability via Director. Example of such use may be integration between Red Hat OpenStack director and Red Hat CloudForms.

Feedback

Feedback is always welcome, please contact the director product managers to clarify questions or provide feedback on how the product lifecycle will affect our customers or our products.