NEW! Mirantis Academy -   Learn confidently with expert guidance and On-demand content.   Learn More


OpenStack embraces the future with GPU, edge computing support

Nick Chase - March 12, 2018
It wasn't that long ago that OpenStack was the hot new kid on the infrastructure block. Lately, though, other technologies have been vying for that spot, making the open source cloud platform look downright stodgy in comparison. That just might change with the latest release of OpenStack, code-named Queens.
The Queens release makes it abundantly clear that the OpenStack community, far from resting on its laurels or burying its collective head in the digital sand, has been paying attention to what's going on in the cloud space and adjusting its efforts accordingly. Queens includes capabilities that wouldn't even have been possible when the OpenStack project started, let alone considered, such as GPU support (handy for scientific and machine learning/AI workloads) and a focus on Edge Computing that makes use of the current new kid on the block, Kubernetes.


While OpenStack users have been able to utilize GPUs for scientific and machine learning purposes for some time, it has typically been through the use of either PCI passthrough or by using Ironic to manage an entire server as a single instance -- neither of which was particularly convenient. Queens now makes it possible to provision virtual GPUs (vGPUs) using specific flavors, just as you would provision traditional vCPUs.
Queens also includes the debut of the Cyborg project, which provides a management framework for different types of accelerators such as GPUs, FPGA, NVMe/NOF, SSDs, DPDK, and so on. This capability is important not just for GPU-related use cases, but also for situations such as NFV.

High Availability

As OpenStack becomes more of an essential tool and less of a science project, the need for high availability has grown. The OpenStack Queens release addresses this need in several different ways.
The OpenStack Instances High Availability Service, or Masakari, provides an API to manage the automated rescue mechanism that recovers instances that fail because of process down, provisioning process down, or nova-compute host failure events.
While Masakari currently supports KVM-based VMs, Ironic bare metal nodes have always been more difficult to recover. Queens debuts the Ironic Rescue Mode (one of our favorite feature names of all time), which makes it possible to recover an Ironic node that has gone down.
Another way OpenStack Queens provides HA capabilities is through Cinder's new volume multi-attach feature. The OpenStack Block Storage Service's new capability makes it possible to attach a single volume to multiple VMs, so if one of those instances fails, traffic can be routed to an identical instance that is using the same storage.

Edge Computing

What's become more than obvious, though, is that OpenStack has realized that the future doesn't lay in just a few concentrated datacenters, but rather that workloads will be in a variety of diverse locations. Specifically, Edge Computing, in which we will see multiple smaller clouds closer to the user rather than a single centralized cloud, is coming into its own as service providers and others realize its importance.
To that end, OpenStack has been focused on several projects to adapt itself to that kind of environment, including LOCI and OpenStack-Helm.
OpenStack LOCI provides Lightweight OCI compatible images of OpenStack services so that they can be deployed by a container orchestration tool such as Kubernetes. As of the Queens release, images are available for Cinder, GlanceHeatHorizonIronic, KeystoneNeutron and Nova.
And of course since orchestrating a containerized deployment of OpenStack isn't necessarily any easier than deploying a non-containerized version, there's OpenStack-Helm, a collection of Helm charts that install the various OpenStack services on a Kubernetes cluster.

Other container-related advances

If it seems like there's a focus on integrating with container-based services, you're right. Another way OpenStack has integrated with Kubernetes is through the Kuryr CNI plugin. The Container Network Interface (CNI) is a CNCF project that standardizes container networking operations, and the Kuryr CNI plugin makes it possible to use OpenStack Neutron within your Kubernetes cluster.
Also, if your container needs are more modest -- maybe you don't need an actual cluster, you just want the containers -- the new Zun project makes it possible to run application containers on their own.

Coming up next

As always, it's impossible to sum up 6 months of OpenStack work in a single blog post, but the general idea is that the OpenStack community is clearly thinking about the long term future and planning accordingly. While this release focused on making it possible to run OpenStack at the Edge, the next, code-named Rocky, will see a focus on NFV-related functionality such as minimum bandwidth requirements to ensure service quality.
What's more, the community is also working on "mutable configuration across services", which means that as we move into Intelligent Continuous Delivery (ICD) and potentially ever-changing and morphing infrastructure, we'll be able to change service configurations without having to restart services.
You can find the full OpenStack Queens release notes here.

Nick Chase

Nick Chase is Head of Content for Mirantis and author of Machine Learning for Mere Mortals.

Choose your cloud native journey.

Whatever your role, we’re here to help with open source tools and world-class support.


Subscribe to our bi-weekly newsletter for exclusive interviews, expert commentary, and thought leadership on topics shaping the cloud native world.