OpenStack 中的孵化到集成

图片来源：

Opensource.com

在一个大型开源项目中，它由许多不同团队开发的相互作用的部分组成，您如何决定哪些部分正式成为核心版本的一部分，哪些部分留在外部？在 OpenStack 中，一个正式的孵化过程有助于准备新兴项目，以便在它们发展和成熟时集成到主代码体中。

历史沿革

Nova（计算）和 Swift（对象存储）这两个项目在 OpenStack 的初始阶段和首次发布时就已成为其一部分。 Nova 最初由 NASA 开发，Rackspace 的 Swift 与其合并到一个计算平台中，创建了 OpenStack 的初始种子。虽然满足了某些云计算工作负载的需求，但仍然需要许多组件来构建完整的平台，并且该项目随着时间的推移而增长。

自首次 Austin 版本发布以来，集成项目的数量稳步增长，沿着通常运行六个月的按字母顺序命名的发布周期。 OpenStack 镜像服务 Glance 在 Bexar 版本中集成。在接下来的正式添加之前，即身份项目 Keystone 和 Web 用户界面 Horizon 在 Essex 版本中添加之前，经历了几个版本。下一个版本 Folsom 添加了网络项目 Neutron 和块存储项目 Cinder。

随着项目的增长和调整，处理新项目添加的过程也随之发展。遥测项目 Ceilometer 和编排项目 Heat 都在 Grizzly 版本中引入了孵化过程，然后在下一个版本 Havana 中正式集成。在此期间，一个负责更新该过程的委员会更加严格地规范化了孵化过程，更仔细地定义了在 OpenStack 的背景下，孵化、集成和核心项目意味着什么，以及哪些测试将确定项目何时准备好进入每个阶段。

最近，数据库服务 Trove 和裸机项目 Ironic 在 Havana 版本中进行了孵化，但只有 Trove 自那时起在 Icehouse 版本中脱离了孵化。 Icehouse 见证了队列服务 Marconi 和 Hadoop 促进器 Sahara 加入孵化，Sahara 计划在即将到来的 Juno 版本中集成。而 Juno 开发周期，即我们当前的周期，增加了密钥管理服务 Barbican 和通过 Designate 提供的 DNS 即服务。

今天的孵化

那么这一切意味着什么？今天的孵化过程是什么样的，一个项目如何完成毕业所必需的事情？

今天，步骤已明确列出，尽管技术委员会仍有很大的解释空间，他们负责确定每个项目在多大程度上符合标准。为了准备好进行孵化，项目必须满足几个标准。

项目应具有清晰的范围，以推进 OpenStack 发展，并且不会不必要地重复现有项目的范围，而是应尽可能利用其他 OpenStack 项目中的功能。
项目应具有合理的 成熟度，拥有一支活跃的开发团队，并且没有计划进行重大的重写。
项目应遵守现有项目所遵循的现有流程，包括托管位置、使用 git 作为版本控制系统、像其他 OpenStack 项目使用的已建立的审查系统、使用官方 OpenStack 邮件列表进行通信以及类似的特征。
项目应具有已开发的 REST API，该 API 应该相当稳定，具有 JSON 实体表示形式和 Python 客户端库。
项目应该可以通过 devstack 构建，以符合其他项目的 QA 要求。
项目应具有文档，至少针对开发人员，并且 API 也必须记录在案。
项目应遵守与其他 OpenStack 项目相同的法律结构，使用 Apache License v2 并遵循其他适用的法律规则，以防止将来使用包含的代码或名称时出现任何障碍。