Oslo Juno 库毕业计划

在 Icehouse 版本的开发过程中，Oslo 团队投入了大量时间来创建流程和工具，以便将孵化器中的代码作为一组新的库发布。除了发布流程本身，我们还思考了如何使其他项目更容易地使用 Oslo 代码。这是我们根据可以预见的尽可能多的因素制定的计划，用于在 Juno 版本中创建 9 个新的库。

毕业顺序

我们需要小心提取每个库的顺序，以避免循环依赖以及库需要从孵化器中获取模块的进一步漂移。我们还需要平衡创建一些计划库的工作复杂性，以及将它们与使用项目集成。

考虑到这两个要求，建议的毕业顺序是

oslo.db - 数据库访问（模型、会话和迁移）
oslo.i18n - 国际化工具
oslo.local - 线程局部实现
oslo.log - 日志设置和上下文感知格式化程序
oslo.text - 通用文本处理工具
oslo.language - python 工具
oslo.serialization - JSON 和 XML 工具
oslo.utils - 杂项
oslo.concurrency - 进程和线程管理工具

虽然 oslo.db 依赖于其他几个计划的库，但迁移到它将花费比其他大多数库更多的时间，因此我们将尝试在周期早期发布它。这意味着 oslo.db 将在一段时间内从孵化器同步更改，但由于我们将尝试最小化这些更改，因此我们预计不会遇到很多问题来保持其更新。随着 oslo.db 依赖的代码从孵化器移动到库中，oslo.db 将更新为使用新的库。

其他库的列表大致按照它们在依赖关系图中的位置排列。我们可能无法及时完成整个列表，以便在 Juno 期间发布它们，但我们预计不会创建比这更多的库。

尽量减少痛苦

我们做了很多计划来准备，但这次迁移不会一帆风顺。我们将尽力使其尽可能无痛。

跨项目单元测试门禁

在 Icehouse 期间创建的新 oslotest 库，让我们有机会弄清楚如何运行跨项目单元测试门禁作业。因此，Oslo 库中的更改现在可以使用其他项目的单元测试进行测试，以便在发布库之前检测回归。

我们将为每个项目/库组合设置一个投票门禁作业，以便在完成集成后，Oslo 库不会以破坏项目的方式更改，并且项目不会以破坏其使用 Oslo 库的方式更改。

更频繁的 Alpha 版本发布

添加到 Oslo 库的新功能不会立即对开发人员可用，因为虽然我们正在使用源代码运行库的门禁测试，以及使用源代码运行 devstack 门禁测试，但项目指定了对已发布软件包的依赖关系。这意味着“tox -e py27”不会找到 master 分支的最新版本，只会找到最新的发布版本。为了减少功能添加到库和在项目中变得可用之间的时间，我们计划在 Juno 周期内发布库的 alpha 版本。创建这些版本的具体过程仍在制定中。

依赖管理

当每个新库与使用项目集成时，先前列在项目需求文件中的仅该库需要的任何依赖项都将被从项目需求文件中删除。例如，如果一个项目需要 sqlalchemy 用于 openstack.common.db，那么当项目更新为使用 oslo.db 时，sqlalchemy 将从项目的 requirements.txt 中删除，并且依赖关系将从 oslo.db 继承。这将使管理我们的通用依赖项列表更容易，并防止由库和项目中的冲突需求引起的错误。

毕业期间的 API 变更

每个新库都满足毕业的稳定性要求，我们将尽力减少 API 变更，但有些变更不可避免。例如，oslo.i18n 需要添加一个公共 API 到 gettextutils，以便可以在同一进程中使用多个翻译域（以支持 Oslo 库中的翻译）。尽可能，我们将以一种方式进行这些更改，以减少使用项目的更改，而无需要求每个项目都具有复杂的集成模块。

为了避免孵化器模块过度同步到项目，这些 API 变更中的大多数将在库从孵化器中移动出去之后进行。这意味着新库的典型“采用”补丁包括删除孵化器版本的模块，可能添加一个集成模块（用于保存先前由孵化代码管理的全局变量，或将项目特定选项传递到库），更新项目中的模块的任何调用者，以及更新项目的依赖项。

跨项目协调

为了使毕业和采用过程更加顺利，我们正在计划更改 Oslo 与其他项目交互的方式。

库负责人

类似于 Nova 具有子部分负责人，并且 Oslo 孵化器为每个模块指定了一个维护者，我们还将为每个新库指定一个负责人。这将为使用项目提供每个库的主要联系人，以回答问题或提供帮助。

项目联络人

现在有比 Oslo 贡献者更多的项目正在使用 Oslo 孵化器中的代码。这意味着我们需要您的帮助来使这些迁移发生。我们要求每个项目指定一个人作为项目与 Oslo 之间的联络人，并协助在代码从孵化器移动到库时集成更改。

联络人应该是项目的核心提交者，但不必是 PTL。联络人应该准备好协助编写和审查项目中的补丁，因为库被采用，并讨论对库的 API 更改，以便使其在项目中使用更容易。

采用顺序

我们计划首先与较小的集成项目合作，然后转到像 nova 和 cinder 这样的大型项目。在较小的代码库上工作将使我们更容易解决每个库迁移过程中的一些问题，而无需在更快移动的项目中进行大型破坏性补丁，这些补丁需要不断地重新定位。

毕业后的孵化器代码

如 Oslo#Graduation 中讨论的那样，在库的第一个版本发布后，孵化器中的代码版本将被视为一个“稳定维护分支”，持续一个完整的周期。例如，这意味着现在在 oslo.messaging 中的 RPC 代码是 Juno 结束时从孵化器中删除的候选对象，并且在 Juno 期间创建的新库很可能在 K 版本结束时被删除。孵化器中的稳定分支将继续保留代码的旧版本，即使它已从 master 中删除。

参考文献

有关库的准备情况和顺序的分析，请参阅 wiki 上的 Oslo/GraduationStatus 和 Oslo/Dependencies。

有关发布新库的流程的详细信息，也记录在 wiki 上的 Oslo/CreatingANewLibrary。

Oslo 在 launchpad 上的 Juno 蓝图列表是：https://blueprints.launchpad.net/oslo/juno

Oslo/JunoGraduationPlans

目录