跳转到： 导航, 搜索

Eventlet 移除

为什么需要移除 Eventlet

Eventlet 虽然曾经因使用“绿线程”进行并发执行而流行，但现在它存在一些限制和问题，使其成为现代项目（如 OpenStack）的过时解决方案

1. 与 Python 最新版本的兼容性问题：

Eventlet 难以跟上 Python 的发展，特别是最新版本（如 Python 3.12 及更高版本）。其一些内部功能，例如“猴子补丁”标准库，现在无法正常工作或导致意外行为。这限制了项目采用 Python 的最新改进，包括关键的安全补丁。

2. 资源和线程管理效率低下：

Eventlet 使用的绿线程可能导致过多的内存消耗和资源管理不善，尤其是在高负载或大规模应用程序下。鉴于 OpenStack 在分布式和高度并行环境中运行，这可能会成为整体性能的重大瓶颈。

3. 维护和安全问题：

Eventlet 缺乏积极的维护，并且没有定期更新来解决安全漏洞和兼容性问题。如果 Eventlet 中的缺陷未及时解决，这会使 OpenStack 暴露于潜在的安全风险中。

4. 过时的并发编程方法：

随着 `asyncio` 或 `concurrent.futures` 等更现代解决方案的出现，这些解决方案与 Python 原生集成，使用 Eventlet 感觉过时了。这些较新的库提供更好的并发管理、更高的性能以及与当前 Python 生态系统的更紧密集成。

5. 无法采用新的 Linux 发行版：

许多现代 Linux 发行版，如 Ubuntu、RHEL 等，现在都附带了不受 Eventlet 支持的较新版本的 Python。如果不迁移离开 Eventlet，OpenStack 将面临采用这些较新发行版的挑战。这将限制采用最新基础设施改进和现代操作系统提供的安全增强功能的能力。

如果迁移未完成可能产生的影响

未能迁移离开 Eventlet 可能会对基于 OpenStack 的项目产生重大影响

1. 阻止 Python 更新：

继续使用 Eventlet 可能会导致 OpenStack 停留在旧版本的 Python 上。这会阻止采用新功能、性能改进以及——最重要的是——新版本 Python 提供的安全补丁。

2. 安全漏洞风险：

鉴于 Eventlet 缺乏维护，未解决的安全漏洞可能会使 OpenStack 系统容易受到攻击。未能迁移到现代解决方案会使基础设施暴露于重大安全风险中。

3. 性能和可扩展性下降：

OpenStack 在分布式环境中处理大型工作负载，Eventlet 的资源管理效率低下会导致速度变慢和故障。如果不进行迁移，这可能会限制 OpenStack 平滑扩展和处理日益增长的数据量的能力。

4. 无法采用新的 Linux 发行版：

如果未完成从 Eventlet 的迁移，OpenStack 将难以支持带有较新版本 Python 的现代 Linux 发行版。Ubuntu 和 RHEL 等发行版现在都附带了与 Eventlet 不兼容的 Python 版本。这将阻碍升级到这些发行版的能力，而这些发行版对于及时了解最新的安全修复程序和性能改进至关重要。

5. 维护成本增加：

继续依赖过时的技术会增加维护成本，因为找到修复或解决技术问题的办法会变得更加困难。这将导致难以长期管理的不断增长的技术债务。

为了确保 OpenStack 的寿命、稳定性和安全性，迁移到 `asyncio` 或 `concurrent.futures` 等现代解决方案至关重要。这将不仅克服 Eventlet 当前的限制，而且确保 OpenStack 能够满足性能、安全性和可扩展性需求。此外，迁移对于支持最新的 Linux 发行版（如 Ubuntu 和 RHEL）至关重要，这些发行版包含与 Eventlet 不兼容的较新版本的 Python。

以下章节旨在指导您完成迁移过程。

迁移里程碑

  • 适配常用库（Oslo 等） - 例如：向 oslo.db 引入 Async Engine Facade，适配 oslo.service 以不依赖 Eventlet；
  • 服务迁移 - 移除 OpenStack 服务中的 Eventlet 用法；
  • 常用库迁移 - 常用库依赖 Eventlet 是因为在更高层级 - 在服务层级 - Eventlet 是必需的，我们不能在服务完全迁移之前从常用库中移除这种 Eventlet 的出现；
  • 移除 Eventlet 的全局需求；
  • 放弃 Eventlet。

发布

目标发布版本

完全移除 OpenStack 中的 Eventlet 肯定需要几个系列，我们至少以 H 或 I 系列为目标。

工作负载调节

  • SLURP 发布可用于引入“冻结”期，在此期间开发速度减慢，以专注于稳定性和文档编写和培训。例如，SLURP 发布可用于减慢我们的迁移活动，并更加关注观察和文档编写。SLURP 发布还可以用于弃用需要弃用的内容或移除与 Eventlet 相关的无用解决方法；
  • 使用非 SLURP 发布来引入破坏性更改。例如，替换 Eventlet WSGI 为选定的替代方案（有关破坏性更改的更多详细信息，请参阅 专业工作组）。

请记住日期

以下是与 Eventlet 移除相关的可能对读者感兴趣的即将到来的活动列表。

定期活动

全局

由于参与者不足，会议已不再继续进行。

以下是跟踪会议的 etherpad https://etherpad.opendev.org/p/flamingo-eventlet-tracking。

Nova

Nova 核心团队同意每周举行一次高带宽同步会议，讨论正在进行的 Eventlet 移除工作。以下是详细信息

[public]Nova Eventlet 移除同步

每周三：14:30-15:00 UTC (16:30 – 17:00 CEST)

视频通话链接：https://meet.google.com/bcy-uqoz-hje

跨项目活动

PTG 2025 年 10 月：星期二 28 下午 3 点 UTC https://etherpad.opendev.org/p/oct2025-ptg-eventlet

项目特定活动

如果您的团队或项目安排了与 Eventlet 移除倡议相关的特定活动，请随时与社区分享您的日期。

以下是即将到来的项目特定活动：- <none>

想讨论吗？

#eventlet-removal

关注 #eventlet-removal 标签。它将在所有相关内容上用于标记此主题

  • gerrit 补丁
  • 邮件列表线程
  • OpenStack OFTC IRC 频道 (#openstack-eventlet-removal)
  • ...

Pop-up 团队

这个社区目标将非常复杂，因此有必要考虑到它对我们社区的影响。这就是 Pop-up 团队的作用。我们需要一种管理社区的方式，并且需要建立旨在改善我们社区工作条件的措施。 这个 Pop-up 团队 的作用是为此提供这些措施和条件，同时保证围绕此主题的社区良好管理。

我们的信条

我们的信条是引导我们与此社区目标相关的决策的方式

  1. 避免有多种管理方式至关重要。统一的方法将简化维护并增强用户体验。
  2. 这是一个社区目标，因此所有社区的声音都很重要。人们应该从全局角度看待这个目标，而不仅仅是从团队或项目为中心的角度。
  3. 我们的决策应该以可持续性为驱动。我们正在以一种放弃黑盒子的方式，我们不应该用另一个黑盒子来代替它。
  4. 如果某个功能默认包含在 stdlib 中，那么我们必须避免依赖提供相同功能的神秘第三方库。

我们的支柱

以下元素代表了 Pop-up 应该体现的不同视角。

协作治理

  • 建立基于共识的治理，其中主要决策在公开咨询（蓝图、规范）或类似 RFC 之后进行投票；
  • 成立一个指导委员会，由来自不同技术团队（nova、neutron、glance、swift、oslo 等）的代表组成，以确保平衡的愿景并防止偏见。

行为准则

制定行为准则，定义尊重、包容和高效协作的规则。对有害或不尊重的行为实施制裁，以保护社区的完整性。

专业工作组

建立 专业工作组 来选择和确定具体的的技术细节，例如使用哪个 python 服务器，使用哪个库（FastAPI vs Flask，HTTPX vs Requests vs AIOHttp 等）。目前我们需要专业工作组专门研究

  • HTTP 决策（服务器选择、应用程序选择（fastapi 等）、特定模式定义）；
  • 任务管理、线程 vs 其他（Asyncio、awaitlet），用于后台任务、延迟任务等；
  • 通用模式定义（超时管理；等）。

这些 专业工作组 将负责审核关键更改。有些人更擅长于此或特定的技术点，这些人应尽可能帮助审核与其兴趣中心相关的关键更改。这些专业工作组的最终目标是定义全局技术路线图。

在这里可以找到专门的工作组列表 https://wiki.openstack.org/wiki/Eventlet-removal#Specialized_Working_Groups_2

导师制度

  • 创建一个导师计划，以指导新的或经验较少的成员。例如，通过提供一些与 专门工作组定义的的技术路线图相关的聚会，来展示本次迁移的特定方面；
  • 将高级开发人员或首席工程师与每个子项目配对，以确保有效的知识转移。鼓励在每个团队中创建一个技术导师的角色，负责在团队成员之间传播知识。

透明度措施

该弹出窗口将负责定期发布项目进展报告和资源使用情况（时间、贡献、迁移的组件、修复的错误）；该弹出窗口将负责创建一个集中仪表板来跟踪任务和截止日期的状态。该弹出窗口将负责通过 IRC 会议和 邮件列表新闻通讯定期沟通。

分散式管理

鼓励子社区/团队（例如，Glance、Cinder 等）在遵循共享的全局路线图的同时，在其领域内做出独立决策。

工作量调节

  • 引入“冻结”期，在此期间开发速度放缓，以专注于稳定性和文档编写和培训。例如，SLURP 发布可用于减缓我们的迁移活动，并更专注于观察和文档编写。SLURP 发布也是弃用事物以计划其删除的好时机；
  • 使用非 SLURP 发布来引入破坏性更改。


所有这些支柱都是为了提高效率、加强协作并帮助避免紧张或瓶颈。有关弹出团队的更多详细信息，请参见下面的链接

专门工作组

专门工作组负责定义全局路线图的各个方面。这些工作组的主要作用是避免出现多种管理方式。这些工作组负责制定统一的方法，这将简化维护并增强用户体验。欢迎所有人。如果您对某个特定方面感到担忧，请不要犹豫，随时表达您的兴趣。以下是目前已确定的专门工作组，此列表可能会在未来几个月内发生变化。如果您觉得缺少某些问题或方面，请随时与我们联系并启动讨论。

HTTP SGI 工作组

该工作组的作用是定义 Eventlet 中 WSGI 功能的正确替代方案。这意味着定义哪个

任务/进程工作组

该工作组将负责为我们交付品中使用的每种类型的任务定义解决方案。延迟任务、后台任务、服务、进程等。这方面包括 oslo.service 的当前重构，请参阅 https://review.opendev.org/c/openstack/oslo-specs/+/927503。

架构、互操作性和技术标准化工作组

该工作组将负责定义最适合我们需求的运行模型。在哪里放置线程或在哪里放置异步。如何确保客户端和库与所有服务保持兼容。新的 oslo.db 引擎 facade 属于该组。围绕 oslo.messaging 执行器的讨论属于该组。如何以统一的方式管理超时等。该组将负责定义如何操作和指导。

入门

请访问迁移指南，网址为 https://removal.eventlet.org 您将找到迁移场景和替代方案（例如线程和 asyncio）的片段。

角色和职责

为了帮助团队管理迁移的组织方面，我们建议以下角色和职责。OpenStack 由多家公司和组织维护，以下结构旨在为团队组织提供一个最小模板，以确保每个人都在同一页面上并清楚地了解我们的工作方式。

Eventlet 迁移很复杂，如果没有一点结构，您的团队可能会受到该迁移的影响。您的交付成果的未来取决于它。

我们强烈鼓励团队采用这种结构。

技术负责人角色

技术负责人将负责

  • 监督：监控团队内迁移的技术进度。
  • 支持：为其他开发人员提供帮助并解决与迁移相关的任何技术问题。
  • 报告：提交定期进度报告，列出受影响的交付成果、Eventlet 模式，并参加与团队产品经理的每月会议。
  • 技术更新：及时了解与迁移相关的最新技术新闻和更新，并与团队分享这些信息。
  • 协调：与产品经理密切合作，以确保团队拥有完成迁移所需的资源。
  • 沟通：充当团队内部关于迁移过程的问题或疑虑的主要联系人。

产品经理的角色

产品经理负责协调和促进团队内的 Eventlet 删除。他们确保为过渡分配必要的资源和时间，并定期跟踪进度。主要职责

  • 优先级排序和计划：确保迁移在团队的路线图和计划中具有优先级。为迁移的每个阶段设定明确的目标和截止日期。
  • 团队支持：为技术负责人和团队提供完成迁移所需的资源和时间。解决可能减慢进度的任何组织或后勤障碍。
  • 进度监控：审查并监控技术负责人提交的进度报告。确保团队满足审计、迁移和报告提交的截止日期。
  • 协调：与其他产品经理合作，以确保所有团队之间的顺利协调过渡。促进团队之间的知识共享，以优化迁移过程。
  • 沟通：参加与技术负责人举行的每月会议，讨论进度、挑战和任何资源需求。定期向利益相关者通报迁移状态。

开发人员的职责

  • 任务 1：确定您的交付成果中当前正在使用的 Eventlet 版本。您可以简单地检查您的需求。您也可以在所有交付成果上使用 beagle，请参阅相关部分。
  • 任务 2：如果版本低于 0.36.1，请准备 Eventlet 需求升级。
  • 任务 3：在接下来的三周内，审计您的代码以识别与 Eventlet 相关的所有依赖项。
  • 任务 4：准备一份进度报告，其中包括
  1. 受影响的交付成果列表；
  2. 这些交付成果中使用的 Eventlet 模式（基于上述定义的模式）。
  • 任务 5：加入我们的 PTG 会议，然后我们一起讨论您的用例。
  • 任务 6：在审计完成后，开始将已识别的 Eventlet 组件迁移到可用的替代方案。目标是在本季度内启动此迁移。

产品经理的职责

  • 任务 1：在您的团队路线图中优先考虑此迁移。从最容易到最复杂的交付成果进行迁移。
  • 任务 2：在接下来的两周内，确定一位技术负责人（最好是高级开发人员或首席高级开发人员），他将负责监督迁移。
  • 任务 3：确保您的团队拥有完成迁移所需的资源和时间。
  • 任务 4：参加即将举行的 PTG 会议和与技术负责人举行的每月后续会议，讨论进度、障碍和下一步措施。

跟踪进度

首先查看 https://review.opendev.org/q/prefixtopic:%22eventlet-removal%22。此页面汇集了与 Eventlet 删除计划相关的所有补丁，并标记了官方主题 (eventlet-removal)。

建议的关键绩效指标 (KPI)

这些 KPI 旨在为管理人员（产品经理）提供一种跟踪和衡量进度的方法，无论从基于团队的角度还是从全局概述来看。

1. 交付成果中 Eventlet 停用率

  • 目标：跟踪交付成果数量，其中 Eventlet 已完全禁用并被替换。
  • KPI：使用替代解决方案（`asyncio`、`awaitlet`、`concurrent.futures` 等）替换 Eventlet 的交付成果百分比。
  • 计算：（迁移的交付成果数量 / 已识别的交付成果总数）x 100。


2. `monkey_patch()` 出现次数的减少

  • 目标：评估逐渐删除对 `eventlet.monkey_patch()` 的调用，这可能会导致不希望的行为。
  • KPI：代码中仍然存在的 `monkey_patch()` 出现次数。
  • 计算：在每个迁移阶段之前和之后识别的 `monkey_patch()` 出现次数总数。


3. 迁移后响应时间和性能

  • 目标：验证迁移到 `asyncio` 或其他解决方案后，交付成果的性能是否得到改善或保持稳定。
  • KPI：迁移后服务的平均响应时间（以毫秒为单位）。
  • 计算：在迁移前后测量响应时间，以检查性能是否得到改善。


4. 迁移后通过自动化测试的百分比

  • 目标：通过验证单元和功能测试是否成功通过，来确保迁移代码的稳定性和质量。
  • KPI：迁移后通过自动化测试的百分比。
  • 计算：（迁移后通过的测试数量 / 执行的测试总数）x 100。


5. 迁移后错误或事件的数量

  • 目标：通过监控与迁移相关的错误或事件数量来跟踪项目迁移后的稳定性。
  • KPI：与 Eventlet 迁移相关的错误或事件数量。
  • 计算：迁移期间和迁移后打开的错误/事件总数。


6. 采用新的 Python 版本

  • 目标：验证团队是否能够在迁移的交付成果中使用新的 Python 版本。
  • KPI：使用最新 Python 版本（例如 Python 3.12）的交付成果百分比。
  • 计算：（使用最新 Python 版本的交付成果数量 / 交付成果总数）x 100。


7. 满足项目迁移截止日期

  • 目标：确保迁移项目遵守最初的时间表。
  • KPI：在截止日期内迁移的交付成果数量。
  • 计算：（在截止日期内迁移的交付成果数量 / 计划的交付成果总数）x 100。

有用的链接

常见问题解答

这个倡议是一个官方倡议吗？

是的，该倡议得到 OpenStack TC 的支持。该倡议是一个 官方 OpenStack 社区目标。该目标 已接受数月并且 现在将成为选定的目标。

OpenStack 迁移完成后，会如何处理 eventlet？

Eventlet 将被正式放弃。官方 Eventlet 存储库将不再进行维护。官方 Eventlet 存储库将被存档。

为什么不简单地维护 Eventlet？

我们有很多原因

  1. 主要原因是，多年来，为了保持 Eventlet 的运行，我们开始分叉过时的旧 CPython 标准库模块。随着 Python 的新版本，这种解决方法肯定需要重复。这种趋势似乎已经随着 Python 3.13 和线程模块出现（请参阅讨论：https://github.com/eventlet/eventlet/pull/966#issuecomment-2344252826）。我们不想将 Eventlet 变成一个维护不善的 CPython 分叉。一个充满安全漏洞的糟糕的。远离这种趋势几乎需要完全重写 Eventlet。
  2. 第二个原因是关于资源。Eventlet 由 1 或 2 名兼职核心维护人员维护，这不足以维持其运行，特别是考虑到前一个原因。我们不想重蹈 log4shell 的覆辙。
  3. 第三个原因是，当迁移完成后，即使迁移由于我们最深入的 Eventlet 用法而很困难，那么我们将安全几十年。我们希望鼓励一种可持续的解决方案。

团队的努力

这是一份与迁移相关的团队创建的文档/补丁列表。如果您的团队拥有文档或补丁，并且未在下面的列表中看到它们，请随时添加。这可以帮助其他团队管理自己的移除工作。

列表

   - https://etherpad.opendev.org/p/neutron-eventlet-deprecation
   - https://bugs.launchpad.net/neutron/+bugs?field.tag=eventlet-deprecation
  • Nova
   - https://review.opendev.org/q/prefixtopic:%22eventlet-removal%22+project:openstack/nova
   - https://gibizer.github.io/categories/eventlet/


您还可以查看官方 gerrit 追踪页面 https://review.opendev.org/q/prefixtopic:%22eventlet-removal%22。

受影响交付物的地图

以下是当前（截至 2024 年 10 月 4 日）使用 Eventlet 并且必须迁移的 Openstack 交付物列表

包含 Eventlet 的现有 spec 仓库

归档

过去的 PTG 活动

Flamingo PTG

Eventlet 跨项目会议

 - Date: 2025 8th April (Tuesday)
 - Etherpad: https://etherpad.opendev.org/p/apr2025-ptg-eventlet
 - Recording: https://www.youtube.com/watch?v=uwtDJpATPik & https://www.youtube.com/watch?v=Epq9EaePzIM

Epoxy PTG

TC/跨项目会议

  - Date: 2024 21st October (Monday)  
  - Time: 1500 UTC  
  - Meeting link: https://meetpad.opendev.org/oct2024-ptg-os-tc
  - Etherpad: https://etherpad.opendev.org/p/oct2024-ptg-os-tc

Eventlet 移除开放讨论时间

  - Date: 2024 23rd October (Wednesday)  
  - Time: 1300-1500 UTC  
  - Meeting link: https://meetpad.opendev.org/oct2024-ptg-eventlet-removal
  - Etherpad: https://etherpad.opendev.org/p/oct2024-ptg-eventlet-removal

Glance - Eventlet 移除会议

 - Date: 2024 24th October (Thursday)
 - Time: 16:00-16:30 UTC
 - Meeting link: https://meetpad.opendev.org/oct2024-ptg-glance
 - Etherpad: https://etherpad.opendev.org/p/oct2024-ptg-glance#L174
从 "https://wiki.openstack.org/w/index.php?title=Eventlet-removal&oldid=186871" 检索