Puppetlabs的Dan Bode在社区发起了一个项目叫做puppet-openstack

原文：

Puppetlabs的Dan Bode在社区发起了一个项目叫做puppet-openstack

NanShan 即时通讯 在这个时候，Puppetlabs的Dan Bode在社区发起了一个项目叫做puppet-openstack，目的是使用puppet来完成openstack的部署，最初这个项目大约由8个相关的module组成，参与人员有cisco,red hat等公司的工程师。这个过程中，我学会了如何使用这些模块来管理现有的集群，掌握了如何使用收集器，配置的存储和导出等等一些高级用法。 在此同时，我又发现其实这些模块并不完美，存在很多的bug，于是我对代码进行了修改，并在本地进行验证后，发送pull request到了puppet社区。社区的人很快就给我回复了，态度很nice，但指出了我非常低级的错误，老外很严谨，小到多一个多行，少一个空格都会在那标记。  我在此过程中，逐渐熟悉了puppet的代码风格，学习了在提交代码前如何对puppet代码和erb模板做语法检查，使用puppet-lint对代码风格进行检查。时至今日，我每看到新人写的代码明显带有其他语言引入的奇怪风格时，都会严格地纠正，即使只是一个空格。  因为openstack是一个迭代频繁的项目，因此配置文件的管理一直是让我们头疼的地方。从最初的模板到后来的concat方式来拼接配置文件，一直没有找到一个可以灵活管理配置文件的方法。后来iweb的magne提了一个patch，使用了自定义resource可以做到对每个选项灵活地管理。在这个过程中，我开始学习如何编写自定义resource，自定义function,自定义facter。  当时又来了一个新任务，部署一个multi region的openstack集群(6个IDC)。我当时兴冲冲地使用site.pp开始定义每个机房的每台服务器的角色。当我写到第2个机房的时候，site.pp已经突破500行了。于是我开始对site.pp进行分割，使用import函数将每个机房节点的配置划分到一个文件中去。但我很快发现这仍然不适合做大规模的管理，于是我开始拿起这本书研究起ENC来，我编写了一个python脚本使用yaml格式的文件来管理节点的配置。现在仍然存在一个问题，那就是节点的配置和数据都存在一起，并不方便管理，并且好多参数的值其实是相同的，何必要重复定义呢？于是我又开始研究了hiera。  那时，我是通过中心的一台puppet master节点来管理所有机房，有时会因为cpu跑满，导致complie catalog失败的情况，于是我又拿起了这本开始研究如何做HA。多台puppet master前面加个LB+KeepAlived解决了这个问题。在这个过程中，我掌握了如何解决多master节点的证书配置和证书同步。  在此过程中，我把对于puppet-openstack的bug修复反馈到了社区，并且开始积极参与社区的ML和IRC中的讨论，涉及puppet的技术细节和openstack业务逻辑的抽象，这对我后来在开发内部项目puppet模块的影响很大。