Contributing Writer

OpenStack Flamingo pays down technical debt as adoption continues to climb

News
Oct 1, 20256 mins

Security improvements and confidential computing enhancements are also part of OpenStack 2025.2, known as Flamingo.

Underwater Light Rays In Dark Stormy Ocean Sea River Abyss Background Darkness Exploration Unknown Fear Hope Hopelessness Deep Arctic Ocean Environment Protection Cold Clean Water
Credit: Shutterstock / Clever Stock

The OpenStack cloud infrastructure project keeps on going, 15 years after it was first created as a joint effort of NASA and Rackspace. 

Today the open-source effort debuted its 32nd release known as OpenStack Flamingo. The new release follows a year of change for OpenStack. In March, the Open Infrastructure Foundation (OpenInfra), itself an evolution of the OpenStack Foundation, was merged into the Linux Foundation. That integration has created operational efficiencies for the organizations, but it hasn’t changed the core focus or technical development practices of OpenStack.

OpenStack today runs on more than 55 million compute cores across production systems around the world. While it started out as a joint effort of two organizations, OpenStack now benefits from a broad base of contributors. Around 480 contributors from multiple organizations including Ericsson, Rackspace, Red Hat, Walmart, Samsung SDS, SAP and Nvidia collaborated over six months to build Flamingo, which introduces almost 8,000 changes. The focus centers on eliminating long-standing technical debt and improving security.

“What we’ve seen over the last cycle is an increase in contributions and number of contributors compared to the Epoxy cycle, which is a good sign that OpenStack is in this plateau of productivity and is there for the long run,” Thierry Carrez, general manager of the OpenInfra Foundation, told Network World.

Reducing technical debt so OpenStack will be around for the next 15 years

The most significant technical work in Flamingo centers on eliminating OpenStack’s dependency on Eventlet, which is a concurrency library originally developed for Python 2 that has seen declining maintenance.

When OpenStack was first created, it was developed with the open-source Python 2 programming language. That version has long since been replaced by Python 3, which has its own concurrency framework, though OpenStack’s individual projects have continued to rely on Eventlet.

During the Flamingo cycle, multiple OpenStack components including the Ironic bare metal service, Mistral workflow-as-a-service, Barbican key management service and Heat orchestration services completed their migrations. They now use Python 3’s native asyncio framework. The Nova compute and Neutron networking projects made substantial progress. Nine other projects are currently in migration.

The work addresses fundamental architectural decisions made early in OpenStack’s history. 

“We made some choices with Python 2 back in the early days, how do we handle concurrency and all that,” Carrez explained. “Our reliance on Eventlet was really a thorn in our side. It was threatening the long-term sustainability of the project, with less and less people working on Eventlet in Python.”

The migration has been under discussion for years. It gained significant momentum during this cycle as the community formed dedicated teams. The benefits extend beyond just using supported code. 

“It has all the benefits from adopting a modern framework that’s being natively developed for the language, versus using something that was developed as an extension for a previous version of Python,” Carrez said.

Security and confidential computing enhancements

Security improvements represent a major theme throughout the Flamingo release. 

The Nova compute project adds support for one-time-use passthrough devices. These remain in a reserved state after instance deletion rather than becoming automatically available. This allows operators to perform security checks or hardware resets before device reuse.

Nova also adds support for AMD Secure Encrypted Virtualization with Encrypted State (SEV-ES). This extends confidential computing capabilities. It protects both guest memory and CPU register state.

The libvirt driver now supports QEMU’s memory balloon autodeflate and free page reporting features. This allows unused guest memory to be automatically released back to the hypervisor. The impact can be substantial for certain workloads.

“The memory performance improvements are more significant,” Carrez noted. “The fact that it now supports the QEMU memory balloon effect allows you to recover memory a lot faster, and so you get a more sane usage of the shared memory you have on your host.”

Beyond Nova, there are some incremental security improvements in other OpenStack projects. 

The Magnum containers-as-a-service project now enables Kubernetes cluster credential rotation. This supports security hygiene practices and enables cluster ownership transfer. The Manila shared file systems services now support bring-your-own-key (BYOK) encryption for shared servers. Finally, the Horizon dashboard now introduces QR code display for TOTP (time-based one-time password) authentication setup. This simplifies multi-factor authentication configuration.

Neutron advances OVN integration 

The Neutron networking project introduces several enhancements focused on OVN deployments and access control in the Flamingo release. 

OVN (Open Virtual Network) is a network virtualization solution that provides software-defined networking capabilities for OpenStack. It uses Open vSwitch to implement virtual networks and layer 2/3 services.

The OVN agent has replaced the OVN Metadata Agent. The older metadata agent will be deprecated in a future release. For operators using OVN, this represents a consolidation of functionality. It simplifies the agent architecture on compute nodes.

Floating IP NAT rules in OVN can now be configured as stateless. The stateless_nat_enabled option potentially improves performance by avoiding connection tracking overhead. This is particularly beneficial for high-throughput scenarios where connection state tracking adds latency. Stateless NAT reduces the overhead associated with maintaining connection state tables.

Neutron adds a new custom API policy rule called context_with_global_access. This allows roles such as auditor to be specified for better access control. Organizations can now grant read-only audit access without full administrative privileges. The granular policy control helps organizations implement proper separation of duties.

The release also includes incremental improvements to NAT rules and policy rules across the networking stack.

Next up: cold soup and AI inference

OpenStack has a six month release cadence between releases. The next release, OpenStack 2026.1 (Gazpacho), is scheduled for April 2026.

Looking forward, Carrez expects the community to complete the Eventlet migration across all projects. This should happen in the next release cycle. AI inference workloads are also emerging as a focus area.

“As we’re seeing inference being one more important type of workload, I’m suspecting we’ll see new additional features and adaptation at the OpenStack level,” Carrez said. “If we get more and more inference workloads, less and less training workloads, that means the way the GPUs are shared across different workloads on the machine is going to evolve and require support at the OpenStack level.”