OpenStack embraces the future with GPU, edge computing support
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.
OptimizationWhile 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 AvailabilityAs 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 ComputingWhat'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, Glance, Heat, Horizon, Ironic, Keystone, Neutron 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 advancesIf 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 nextAs 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.