Oslo

Oslo 汇集了通用的代码审查员和专业的 API 维护者，他们共同致力于解决 OpenStack 项目中的技术债务，并使 OpenStack 项目的部署和开发体验保持一致。

OpenStack 项目共享许多通用的设计模式和实现细节。在 OpenStack 历史的早期，这导致大量代码从一个项目复制到另一个项目。Oslo 项目的创建是为了解决这种情况，并为多个其他 OpenStack 项目通用的代码提供一个存放地。采用 Oslo 库可以使项目更类似于 OpenStack 的其余部分，而这种一致性反过来又可以改善操作员/部署者的体验。

库

Oslo 团队管理着一套不断增长的 Python 代码库，这些库是从头开始创建、从社区外部采用或从其他 OpenStack 项目中提取的。每个库都有自己的核心审查团队，结合了问题领域专家的努力和 Oslo 核心审查团队的整体努力。

以下是 Oslo 团队管理的库的一些示例

oslo.config

oslo.config 库提供了用于管理配置选项定义、验证、配置文件解析和命令行选项处理的工具。

oslo.messaging

oslo.messaging 库实现了常见的进程间通信模式，例如通知和 RPC。它包括用于不同后端（如 RabbitMQ、AMQP 1.0 和 ZMQ）的驱动程序。这种可插拔的后端模式在 OpenStack 中很常见，作为为熟悉不同工具堆栈的部署者提供选项的一种方式。

oslo.log

oslo.log 库是 Python 标准日志记录工具的包装器，将它们与 oslo.config 结合起来，并应用 OpenStack 特定的要求。使用 oslo.log 的项目可以更容易地为部署者设置一致的日志记录，从而更容易使用 Logstash 等工具对日志进行后处理。

简要历史

Oslo 项目始于 Bexar 版本的发布时间框架，并在 Grizzly 周期之前获得 PTL 职位后缓慢发展。在 Grizzly 期间，该团队采用了“Oslo”这个名称（基于奥斯陆和平协议和“带来和平”到 OpenStack 项目，该名称不是首字母缩写词）。使命宣言在此期间得到巩固，并建立了核心团队，第一个正式发布的 Oslo 库是 oslo.config。 oslo.messaging 在 Havana 周期中发布。在 Grizzly 之后，孵化代码的数量继续增长，同时团队开发了管理它的工具。在 Juno 和 Kilo 周期期间进行了一次重大的毕业推动，到 Liberty 周期早期，总共有 26 个库。

孵化器

虽然该团队更喜欢根据需要从头开始开发新库，但 Oslo 库的一个重要代码来源是现有项目中被确定为对另一个项目有用的代码。现有的实现可能与应用程序紧密耦合，需要进行修改才能使其更通用。Oslo 团队经常使用特殊的孵化器仓库来演化代码的 API，因为它从原始项目中提取出来，依靠“受管理的复制和粘贴”来允许 API 中的破坏性更改，实际上将结果复制回少量早期消耗项目。随着 API 的稳定，代码将毕业成为一个合适的库。

有关更多详细信息，请参阅 Oslo 团队规范仓库中的Oslo 孵化器。

联络人

有更多的项目正在使用 Oslo 孵化器中的代码，而不是 Oslo 贡献者。因此，Oslo 团队依靠每个消耗项目中“联络人”来协调工作，因为新代码通过孵化或发布新库。当前的联络人列表在 wiki 中的跨项目联络人页面上列出，并且在Oslo 联络人计划规范中可以找到更多详细信息。

命名库

目前 Oslo 库使用了三种命名方案，每种方案都旨在表明库预计在何处有用。

  1. 用于 OpenStack 项目的生产运行时依赖项的库遵循库和 dist 的命名模式 oslo.something，但使用 oslo_something 作为顶级包名称，以避免使用 oslo. 命名空间包。

    生产运行时依赖项的示例包括 oslo.config 和 oslo.messaging。

  2. 用于 OpenStack 项目的非生产或非运行时依赖项的库应遵循命名约定 oslosomething（省略“oslo”和“something”之间的“.”）用于库、dist 和顶级包。

    非生产依赖项的示例包括 oslosphinx 和 oslotest。

  3. 无论它们在 OpenStack 中的使用方式如何，如果库可能在 OpenStack 外部普遍有用，则应赋予其描述性和唯一的名称，而不使用任何形式的“oslo”前缀。

    Oslo 名称的其他示例包括 pbr 和 taskflow。

有关更多详细信息，请参阅 Oslo 命名策略规范。

参见