美国时间2月1日晚，由UnitedStack有云DevOps团队提交的“Puppet-oslo”项目在快速并入“Big tent”（大帐篷）项目集后，被OpenStack社区的Technical Committee（技术委员会，简称为TC）正式接受，成为受其正式监管的Puppet-OpenStack官方项目。这也是继网络诊断项目Steth并入“大帐篷”后，来自UnitedStack有云的第二个Upstream项目成功并入OpenStack社区。从项目向社区提出，到最终成为Governance项目，Puppet-oslo项目共耗时12天。

Puppet-oslo提交历程回顾

Puppet-oslo项目由UnitedStack有云创始工程师之一、现任UnitedStack有云研发总监余兴超设计并提出，余兴超也是OpenStack社区Puppet Modules项目核心开发者，长期专注于自动化运维与持续交付领域。2016年1月初，余兴超首先在Openstack-dev邮件列表中提出了Puppet-oslo项目，这一提议得到了Puppet项目PTL Emilien Macchi的大力支持。仅花费了3天的时间，Puppet-oslo项目就成功并入“大帐篷”开发模式，并且进入申请Governance项目序列。

在此期间，UnitedStack有云的DevOps团队与包括OpenStack发行版本周期管理项目PTL Doug Hellmann等社区技术领袖进行了深入的交流，并且最终获得OpenStack基金会工程主管、OpenStack技术委员会主席兼发行版本经理Thierry Carrez的批准，正式合并入Governance项目集，成为Puppet-OpenStack官方项目。目前该项目的主要贡献者为余兴超和UnitedStack有云DevOps工程师廖鹏辉，Puppet项目PTL Emilien Macchi也在第一时间成为该项目的贡献者。

Puppet-Oslo项目贡献分布

Puppet-oslo能够解决哪些问题？

在OpenStack大家庭中，Puppet是专注于提升OpenStack云部署的IT自动化可扩展性和可靠性的关键模块，严格遵循OpenStack社区开放源代码、开放式设计、开放式开发的宗旨。在OpenStack社区中，Puppet-OpenStack是一个快速发展并扩充的子集。目前，该社区已经有了近30个Puppet modules（模块），而每个module都独立管理着与Oslo.*相关的配置参数。在Puppet项目的高速成长的过程中，这种管理模式对代码的一致性和维护的便利性带来了极大挑战。

举例来说，我们需要调整[oslo_messaging_rabbit]下的某一个参数时，社区开发者将不得不对每个module分别进行修改，一个简单的参数调整需要提交多达20多次。与此同时，这样的操作也带来了大量的冗余代码，明显不符合开源社区所提倡的DRY（Don’t repeat yourself）原则。

Puppet-solo项目合并后，每个module与oslo相关的配置逻辑被完全抽离出来，进行统一管理，有效地减少了代码冗余和维护工作量。借助Puppet-solo项目的配置逻辑，不同Puppet module之间的协作将更加便捷，代码大幅精简，同时代码的管理与维护更加便捷和高效。

Puppet-Oslo架构改进对比

我在做puppet-keystone的部分代码重构时，使用一个define类型去统一管理所有服务的authtoken配置。受到这个思路的启发，发现可以运用相同的方法去统一的管理各服务的oslo.*项目，因此在openstack-dev邮件列表上提出了puppet-oslo项目，目的是将每个module中与oslo相关的配置逻辑完全抽离出来，统一进行管理，有效地减少代码冗余和维护工作量。

OpenStack社区对于这部分的优化工作早在温哥华Design Summit上已经进行过专门的讨论，但由于各个项目所使用的oslo.*组件并非统一，因此当时得出的结论是不做（http://my1.fr/blog/puppet-openstack-plans-for-liberty/）。这个话题也慢慢沉寂下去。UnitedStack有云的DevOps团队花了2天时间调研Openstack核心项目以及比较活跃的相关项目，给出的结论是绝大数项目主分支（Mitaka）的oslo.*版本是一致的，可以使用puppet-oslo进行统一管理。

——UnitedStack有云研发总监、OpenStack社区Puppet Modules项目核心开发者 余兴超

为什么加入Puppet-oslo项目？

在Puppet-openstack部署过程中，我发现许多废弃或者变更的参数在某些puppet模块中没有来得及变更。于是开始将这些参数变更的patch提交到社区的puppet项目，这些参数中的oslo相关参数本来在每个模块中都应该是一致的，但由于每个puppet模块各自维护自身的oslo参数，更新的进度可能各不相同，也导致了配置的不一致。

正好得知我的Leader余兴超在与社区讨论后启动开发一个叫做Puppet-oslo的新项目，用这个项目来为每个Openstack项目配置oslo相关参数，正好解决了很多oslo参数维护的问题。于是我当天就加入到了这个项目的开发，幸运的是，下午项目就进入社区Big Tent，随后又成为OpenStack官方项目。这充分证明了社区对Puppet-oslo项目的极大兴趣，因为它从根本上减小了 Puppet 项目参数的维护难度。今后我们 将继续参与这个项目的开发，争取早日开始在Puppet-openstack项目中试用并推广。

——UnitedStack有云DevOps工程师 廖鹏辉

践行Upstream之路

在OpenStack基金会于2015年5月正式推出“Big tent”开发模式后，UnitedStack有云持续深化Upstream First的开发模式，与上游紧密保持同步。在与OpenStack社区同步代码的同时，UnitedStack有云专注于不同领域的技术团队也在积极向社区提交新的功能，在丰富社区技术模块的同时，贡献代码、与全球OpenStack开发者展开协作，同时接受OpenStack社区的严格监管。

从2013年2月创立之日起，UnitedStack有云一直秉承Upstream First的开发模式，全面兼容社区功能，并且提供更加贴近中国客户需要的高级功能。而借助全新的“Big tent”模式，这些由中国工程师设计和开发的新功能或新工具，能够更加快速地被OpenStack社区所接受，在全球协作的开发社区中被不同国家的开发者所使用，同时这些项目的完善和丰富也可以得到全球开发者的贡献和支持。进入2016年，UnitedStack已经有两个新项目（Steth和Puppet-oslo）成功并入OpenStack社区。

如何加入Puppet-oslo？

Puppet-oslo项目正在寻找优秀的开发者和文档工程师，如果你希望加入该项目的开发团队，可以关注IRC频道#puppet-openstack。

目前，Puppet-oslo已经正式成为Puppet-OpenStack社区的正式项目。OpenStack社区很可能从OpenStack-Keystone或者其他某个项目开始试用Puppet-oslo项目。如果可行，将逐步推广其他的Puppet-openstack项目。您可以通过https://review.openstack.org/#/c/270872/查看该项目详情，有兴趣的开发者也可以从launchpad.net/puppet-oslo关注该项目。