Red Hat OpenStack Platform 9 is here! So what’s new?

This week we released the latest version of our OpenStack product, Red Hat OpenStack Platform 9. This release contains more than 500 downstream enhancements, bug fixes, documentation changes, and security updates. It’s based on the upstream OpenStack Mitaka release. We have worked hard to reduce the time to release new versions and have successfully done so with this release! Red Hat OpenStack Platform 9 contains new Mitaka features and functionality, as well as the additional hardening, stability, and certifications Red Hat is known for. Of course, there continues to be tight integration with other key portfolio products, as well as comprehensive documentation.

So what are some of the main new highlights for this release?

Automated updates and upgrades

Red Hat OpenStack Platform director 9 provides backward compatibility 1 version back. This means you can use director 9 to deploy and manage Red Hat OpenStack Platform 8. And starting with version 9, the lifecycle support for director has been increased to match the lifecycle support for the core.   

When you decide it’s time to upgrade, director will perform the required actions step-by-step. One of these steps will involve the enablement of the new alarms API (called Aodh--more on that later) and the migration of the old Ceilometer Alarms.

Heat resource chains and a new hook for pre-delete

Previously, customers using Heat could only specify a single monolithic template for orchestration. Now multiple templates can be supported simultaneously. This simplifies the use of Heat templates and provides greater flexibility.

Also new in version 9, Heat can perform cleanup actions, like closing network connections, logging and event, or syncing filesystems. This allow for proper shutdown of virtual machines managed by Heat.

Live migration improvements

Compute now automatically detects block vs. shared storage when performing the live migration of an instance, which can accelerate the process by leveraging the shared storage. It’s also now possible to monitor the live migration progress and even pause or cancel a virtual machine in the middle of the migration from the old to the new hypervisor.

Thread-aware CPU pinning for NFV and HPC workloads

Earlier releases of Compute added support for instances with dedicated CPU resources and NUMA topology awareness. By default, it would prefer using sibling threads for vCPUs using simultaneous multi-threading (SMT), although its behavior could only be changed cluster-wide with the configuration file options. Now that behavior is configurable dynamically within individual image properties and extra specifications.

• Prefer: the default, it prefers placing guest vCPUs on sibling threads where they are available. Host may or may not have SMT support.
• Isolate: this isolates threads placing guest vCPUs on different physical cores. On systems with SMT support, it means that no vCPUs from other guests are placed on those cores.
• Require: this forces the use of thread siblings. The host must have SMT support.

Ability to purge a project’s networking

Previously, after deleting a project, you had to deal with stale resources that were once allocated to the project. This included networks, routers, and ports. These stale resources had to be manually deleted and deleted in the correct order. Red Hat OpenStack Platform 9 has addressed this issue using the Neutron purge command to delete the Neutron resources that once belonged to a particular project.

This reduces the possibility of orphaned resources (IPs, ports, and DHCP servers) living in the system without an owner and possibly unnecessarily consuming resources. Previously, only the admin could see and clean them either manually or with scripts. Now the admin (after deleting the tenant) can remove the networking artifacts in a coherent fashion. No more wasting resources, like floating IPv4 addresses, after removing a project.

Gnocchi

Gnocchi is a time-series backend for ceilometer that works with Ceph or Swift and provides high performance storage and queries of the metrics collected, which is highly scalable and better than previous implementations. With Red Hat OpenStack Platform 9, Gnocchi is promoted from “tech preview” to “fully supported”, but it will not deploy by default by Director--it needs to be enabled by the operator.

Aodh

The new Alarming component that replaces Ceilometer Alarms is called Aodh (pronounced like the letter “A”). It offers a separate API for configuring and triggering custom Alarms by tenants. Director’s installation tool will enable Aodh and migrate users to the new API.

These are some of the main highlights for product features. As a reminder to our customers, Red Hat Cloudforms is included free of charge with Red Hat OpenStack Platform (quickstart documentation available here), to manage both infrastructure and running workloads. And for version 9, Red Hat CloudForms offers the following new features:

• Tenant Management:  SSH Key Management, Volume and Images Management, Right Size Recommendations for CPU and Memory, Instance Flavor Reconfiguration (i.e. from m1.tiny to m2.xlarge), Live Migration, Events from Ceilometer, etc.
• Infrastructure management (undercloud): Scale In and Out (add or remove overcloud nodes), evacuate all or selected instances from a host that needs to be decommissioned; Also, the ability to do Capacity Planning to evaluate how many VMs of a particular profile (e.g. currently running on VMware) can fit on our OpenStack deployment.

Ready to learn more?

Check out our Red Hat OpenStack Platform page, where you can request a free 60-day trial). Or visit our customer portal, where you can:

• View the list of supported components and certified plug-ins
• Browse the official documentation page
• Check out the version 9 release notes