1.4　OpenStack项目发展流程

经过9年多的发展，OpenStack已经从最初的Nova和Swift两个项目发展到目前形形色色的上百个项目，但是OpenStack的每个版本仅仅包含其中少量的一些，那么这里的问题就是：一个项目从最初的创建到最终被包含在OpenStack发布版之中，需要经历什么样的阶段呢？

1.4.1　新项目

互联网时代最缺的是什么？毫无疑问是Idea。同样，在OpenStack里，一个新项目的源泉也是新的Idea。这个Idea的产生既可能来自AWS里的功能，也可能来自OpenStack使用者的需求。当这个Idea逐渐成熟且工作量足够大，以致无法在现有的某个OpenStack项目中承载时，就有必要成立一个独立的新项目。

项目的发起者可以是一个人，但更有可能的是一群人。他们会发动开源社区，推广这个新项目并吸引一批开发者来共同开发。这些开发者形成的团队会在OpenStack邮件列表上讨论问题，并定期举办日常例会。

在新项目成立早期，如果还没有PTL，则团队内部会选举并指派一个领头人带领整个团队的开发，以及主持每期例会。

由于该项目是开源的，就会源源不断地有新的开发者加入开发团队中，同时，也会有人审视并吸收类似的开源项目，以避免重复工作。最后，项目会渐渐成熟，形成自己的目标、计划和代码库。为了方便起见，项目发起者们一般会先将项目存放在stackforge目录中。

最初项目的版权最好是Apache 2.0，这样就与OpenStack保持一致了。当有一天新项目被集成到OpenStack发布版中时，就不用重新定义和处理版权问题了。

值得一提的是，当一个项目还是新项目时，它是在OpenStack之外进行开发的，这是该项目必须经历的一个阶段，但是项目发起者们却可以利用任何OpenStack正在使用的工具去管理该项目，例如，使用Launchpad工具作为跟踪Bug和blueprint的工具。

经过若干月或若干年后，一旦项目发起者认为该项目足够成熟了，他们就可以向OpenStack技术委员会提出OpenStack孵化请求，并等待该项目被批准成为OpenStack孵化项目。

1.4.2　孵化项目、集成项目和核心项目

1.孵化项目

一个项目在被集成到OpenStack发布版之前，成为孵化项目是必经阶段。在这个阶段里，项目开发人员需要了解OpenStack的发布节奏、发布流程，以及要成为集成项目需要完成哪些工作等内容。同时，也可以尽量寻求与其他项目合作或合并的机会。一般来说，这个阶段至少需要持续两个开发周期。

在孵化期间，孵化项目都会被移植到OpenStack命名空间和目录中。在一个开发周期结束时，OpenStack技术委员会会对孵化项目进行考核，理论上只有经历了两个开发周期的孵化项目才能被选为考核目标。

2.集成项目

如果该项目的考核结果被证明是足够成熟的，并且该项目已经准备好被集成到OpenStack发布版中，该项目就会被批准从孵化期“毕业”，成为OpenStack集成项目。在下一个开发周期里，该项目就会正式成为集成项目，并成为OpenStack正式家族成员之一。

比如，监控计费项目Ceilometer成立于2012年，当时的最初想法是提供一套基础架构用于收集来自各种OpenStack项目中的数据，为运营商计费提供参考依据。Ceilometer在2012年的Grizzly开发周期里成为孵化项目，并在2013年4月的Havana开发周期里，正式地被批准成为OpenStack的集成项目。

3.核心项目

核心项目的含义在2013年有所改变，那时OpenStack项目的管理刚刚被转交给OpenStack基金会。在此之前，所有被集成在OpenStack发布版中的项目都被称为核心项目，包括Nova、Swift、Glance、Cinder、Neutron、Horizon和Keystone。

此后，“核心”这个词变成了OpenStack基金会在OpenStack发布版里对某个项目进行贴标签的特有名词，“核心”的使用也就被限制了。可以这么说，核心项目是集成项目的一部分，是它的子集。当OpenStack基金会的董事会认为某个集成项目能达到某些要求时，可以为该集成项目贴上“核心”这个标签。

在2013年之后，所有从孵化期“毕业”且被集成在OpenStack发布版里的项目都统一称为集成项目，如Ceilometer、Heat和Trove都是集成项目，但针对之前的那7个核心项目，我们仍称它们为核心项目。

无论是核心项目还是集成项目，都代表着该项目已经成为OpenStack的正式家庭成员，在每半年发布的OpenStack版本里，都会包含该项目。这也意味着对核心项目和集成项目有着更高的要求，无论是新功能开发流程及代码稳定程度还是项目的开发周期，都必须与OpenStack的节奏保持高度一致。

OpenStack项目的孵化集成模式的流程如图1-7所示。

1.4.3　大帐篷（Big Tent）

但是，从2015年发布的版本Liberty开始，OpenStack废弃了原来的孵化集成模式，进入了一个全新的发行模式，即引入了所谓的“大帐篷”一词，使得OpenStack发行变得更加松散和自由。

在之前的孵化集成模式里，新项目首先要被孵化，然后在成熟到一定程度时，经过申请和投票决定是否把它放到集成项目里，并且它的发布版必须与OpenStack发布同步。

这样一来，集成项目丧失了自由度和灵活性。随着云计算技术的快速发展，以及用户需求的快速增长和动态变化，大量新项目在希望成为OpenStack项目时就遇到了瓶颈。为了满足市场的动态变化，大帐篷模式应运而生。OpenStack基金会用文档定义了OpenStack流程及其开源社区的工作方式，只要该项目符合这些流程，并经过审核批准后，就可以成为大帐篷的一员，进而成为OpenStack项目，而且该项目的发行步骤也可以根据自身的特殊要求进行小范围调整，没有必要与OpenStack发布版完全一致。比如，如果没有大帐篷，也许Magnum项目就不会这么容易地成为OpenStack项目。

一个大帐篷项目只负责在某个空间里解决某一特定的问题，但由于成为大帐篷项目变得更加容易，这种机制也更容易产生竞争，也就是说，很有可能在大帐篷里有多个项目是解决同一或类似问题的，但对于用户来说这反而是一件好事情，因为用户的选择范围更加广泛了。

在大帐篷里，OpenStack仍然保留了6个核心项目，即Nova、Cinder、Swift、Neutron、Keystone和Glance，只有原核心项目Horizon被放在了非核心项目里。而以前的集成项目都无一例外地被放在了大帐篷的非核心项目中。

诚然，大帐篷也有一定的缺点。比如，某些项目极可能是由来自同一家公司的开发者主导开发的，那么该公司会对这些项目具有绝对的话语权，使得这些项目慢慢地朝着垄断和封闭的方向发展。另外，大帐篷降低了新项目变成OpenStack项目的门槛，使得OpenStack涌现大批项目，而有些项目甚至不知道是做什么、解决什么问题的，同时项目质量也难以掌控，这增加了基金会的管理难度。