Red Hat OpenStack Platform Director Life Cycle
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.
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?
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 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 Platform core follows upstream OpenStack cycles closely: every 6 months there's a new OpenStack release (named Juno, Kilo, Liberty and so on) and we follow with a productized version using a number (6 for Juno, 7 for Kilo and so on).
Red Hat OpenStack director has aligned life cycle support with the core product.
For more details please refer to Red Hat OpenStack Platform support. (1)
(1) Red Hat OpenStack Platform director had a shorter life cycle for versions 7 and 8. Since version 9 director has aligned its support life cycle with core and retrospectively applied this change to versions 7 and 8. All versions of Red Hat OpenStack Platform director are therefore aligned with the core product now.
Red Hat OpenStack Platform director can deploy and manage one previous major version of Red Hat OpenStack Platform core. Main purpose for this feature is to safely handle upgrades from the previous version to the current one.
Example of this functionality is, that Red Hat OpenStack Platform director 9 is able to deploy, scale, and update Red Hat OpenStack platform core 8. Furthermore, it is able to move (upgrade) to the same version as director itself (i.e upgrade from core 8 to the latest version of 9) .
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 (2) 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.
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 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.