OpenStack Eventlet Removal Resources
OpenStack has embarked on a significant technical initiative to remove Eventlet dependencies across all its components. This section provides resources, updates, and insights into this community-wide effort.
Why is OpenStack Removing Eventlet?
The OpenStack Technical Committee (TC) has established Eventlet removal as a top priority for several key reasons:
Python Evolution
Eventlet faces significant compatibility issues with all recent Python versions starting from Python 3.12. These challenges are further exacerbated by Python 3.13 and the PEP 703 "GILectomy" implementation, making migration critical for ensuring future compatibility.
Maintenance Challenges
Diminishing maintenance activity in the Eventlet project means bugs accumulate faster than they're fixed, creating reliability issues.
Compatibility Problems
Integration issues between Eventlet and important libraries like RabbitMQ cause persistent operational problems in OpenStack deployments.
Performance Optimization
Benchmarks have shown performance advantages with alternative concurrency implementations compared to Eventlet's approach.
OpenStack PTG Updates
The OpenStack Project Teams Gathering (PTG) events have featured significant discussions about Eventlet removal. Explore the documentation from these sessions to understand the community's approach and progress.
Updates from future PTGs will be added here
Project-Specific Resources
Different OpenStack projects have adopted various approaches to Eventlet removal. Below are examples and resources from specific components.
- Octavia: A Complete Migration Case Study
- Neutron: Eventlet Removal Patches
- Oslo.service: New Threading Backend
- Nova: Eventlet Removal Progress Tracking
- Nova: Balazs Gibizer's Blog on Eventlet Migration - Detailed articles tracking Nova's progress
Additional project resources will be added as they become available
Current Migration Status Summary 🔗
The progress of Eventlet removal varies across OpenStack projects. Here's a high-level overview as of April 2025:
| Project | Status | Approach |
|---|---|---|
| Octavia | Completed | Complete migration since 2017 |
| Mistral | Nearly Complete | Comprehensive approach with minimal incremental steps |
| Neutron | Significant Progress | Dual-mode support during transition |
| Oslo Libraries | Significant Progress | Deprecated Eventlet features, oslo.db supports asyncio, developing threading backend for oslo.service |
| Glance | Partial | Core works without Eventlet; some optional features still depend on it |
| Nova | In Progress | Service-by-service approach with dual-mode support |
| Cinder | In Progress | Starting with Volume Manager, then other components |
| Manila | In Progress | Multi-cycle approach, targeting completion in Guppy cycle |
| Heat | In Progress | Will use new oslo.service implementation, discontinuing WSGI server |
| Ironic | In Progress | Component-by-component approach, challenges with IPA |
| Designate | In Progress | Top priority for Flamingo cycle |
| Swift | Planning | "Canary node" approach starting with proxies |
| Blazar | Planning | Evaluating alternatives to Eventlet WSGI |
| Watcher | Planning | Beginning examination of Eventlet usage |