今年五月刚结束的Juno OpenStack Summit是半年一度的Openstack盛会，抛去那些迷花渐欲乱人眼的商业活动，我们来看一看本届summit puppet-openstack社区有哪些新的动态，有哪些新的开发计划。
鉴于上次icehouse puppet design summit主要是以core members和active dev member为主的纯技术讨论会议，导致好多感兴趣的用户来听了也不知所以然。
因此，本届summit中又新增一个称为Juno puppet operators meetup的会议，旨在提供一个用户和开发人员相互交流的机会，听取用户的意见和建议，分享部署和运维的经验，吸引了大量的开发者/用户前来参加。
前PTL Dan Bode在Havana Release之后便离开了Puppetlabs，创建了以自己名字命名的咨询公司，开始退居二线，云游世界，因此，这次meetup由puppetlabs的Chris Hoge负责主持。
Topic 1 Who is using Puppet to manage Openstack ?
Chris一开始询问有哪些公司使用了Puppet来管理Openstack，我整理了一下在Etherpad上的记录，如下表所示:
表1 使用puppet管理openstack的公司
| 公司 | 系统版本 | puppet组件 | puppet组件版本 |
| Aptira | CentOS 6 | puppet_openstack_builder | Havana |
| Catalyst | Ubuntu 12.04 | puppet openstack modules | Havana |
| CERN | Scientific Linux | puppet openstack modules | Havana |
| Cisco | Ubuntu12/14 | puppet_openstack_builder | Grizzly/Havana/Icehouse |
| Comcast | Ubuntu | puppet openstack modules | Essex/Grizzly/Havana |
| Cybera | Ubuntu | puppet openstack modules | Grizzyly/Havana |
| despegar.com/decolar.com | Ubuntu 12.10 | custom modules | Folsom |
| eNovance |
Ubuntu12.04/14.04 Debian Wheezy RHEL 6.5 |
puppet-openstack | Grizzly/Havana/Icehouse |
| GoDaddy | CentOS 6 | puppet openstack modules | Havana |
| iWeb | Ubuntu 12.04 | puppet openstack modules |
Havana Icehouse for Swift only |
| Mirantis | Ubuntu 12.04 CentOS 6.[3-5] | puppet openstack modules | Folsom/Grizzly/Havana/Icehouse |
| MIT CSAIL | Ubuntu 12.04 | puppet openstack modules | Havana |
| Nimag/Camptocamp | Ubuntu 12.04 | puppet_openstack_builder | Havana |
| Oracle | Solaris 11.2 | puppet openstack modules | Grizzly |
|
Pixelpark AG |
Fedora 20 | puppet openstack modules(except Ceph) | Icehouse |
| Red Hat | RHEL | puppet openstack modules | Grizzly/Havana/Icehouse |
| SCEA | Ubuntu 12.04 | puppet openstack modules | Essex |
| Sina | Ubuntu 12.04 | puppet openstack modules | Essex/Folsom |
| Time Warner Cable | Ubuntu 12.04/14.04 | puppet openstack modules |
Ubuntu 12.04 for Havana Ubuntu 14.04 for Icehouse |
| Unitedstack | Centos 6.[4-5] | puppet openstack modules and custom modules | Folsom/Grizzly/Havana/Icehouse |
小结：
从上述的数据来看，
1. puppet-openstack项目虽然起步于Essex版本，但已经得到了广泛的应用；
2. Puppet openstack modules支持目前绝大数主流的Linux OS系统，大多数公司会选择Ubuntu，其次是RHEL系(RHEL/CentOS/Fedora)；
3. 绝大数公司在使用havana stable分支的core openstack modules代码；
4. 使用puppet-openstack模块作为composition layer目前远高于puppet_openstack_builder；
5. 不少公司使用了定制化模块来满足内部业务需求
6. 有两家公司在puppet openstack项目的基础上，开发了用于简化部署的工具：
a. Mriantis的Fuel底层封装了puppet openstack modules(有定制化修改)，提供更为方便快捷的部署方式，同时支持Ubuntu和CentOS (是因为RedHat投了Mriantis LOL)；
b. RedHat的packstack也是类似的原理，直接使用了upstream的puppet openstack modules，不过只支持自家的RHEL系列 :)
来自Openstack官方的User survey作了关于部署工具的最新数据统计，Puppet在不同的集群规模上(非POC)均排名第一，其次是devstack：
图1 部署工具占有率分布图
Topic 2 How are you using Puppet to manage Openstack?
第二个话题是关于通过何种方式使用Puppet来管理Openstack集群。
大致可以划分为以下5类：
- 直接使用upstream的代码，并保持更新
- 使用upstream的代码，但只在必要时进行更新
- 使用upstream puppet模块和私有的composition layer
- 使用未修改的核心模块，但不使用puppet-openstack作为顶层的composition layer
- 使用定制化模块和针对特定节点的composition(Cybera)
小结：
第1种和第4种方法是比较常见的使用方式。
第1种方式适合小规模部署或者没有定制化的需求，例如搭建一个poc环境，开发环境，测试环境等等；
往往在有一定业务需求的情况下，社区的puppet-openstack模块不能满足（必然不能满足，因为这个模块的目的是满足通用性，鼓励大家在此基础上做定制化的修改），会进行二次开发，因此，多数常常会采用第4种方法。例如，我们就使用了puppet-sunfire模块用于替代puppet-openstack模块。
Topic 3 What are your experiences ?
第三个话题是分享关于使用Puppet部署Openstack遇到的困难和经验。
第一个问题是关于puppet module升级的流程：由于每个节点的数据存储在hiera/ENC中，当升级puppet modules时，那么用户如何知道哪些参数将会变更，哪些参数需要进行调整。
这里引申出如何管理弃用参数，当前对于涉及到参数名称的变更时，会要求提交者有完善的逻辑对其进行处理，若用户用到了弃用参数，会调用warning函数发出弃用警告信息，但仍然有效。
会议上约定了两条准则：
- 弃用参数应该在README或者Release中说明
- 注明参数最终会在何时被移除
关于是否最终删除这些废弃的参数，一些开发者认为尽可能地保留这些参数，以保证向前兼容。
2. 代码审查应该快速有效
问题1：有些开发者认为社区的代码审查太慢了，拖得太久，主要是puppet-openstack社区不像其他社区那么单一：
首先多达十几个项目，从puppet-nova,puppet-keystone,puppet-heat模块到puppet-designate,puppet-ceph等，需要代码审查者熟练掌握Openstack每个项目的组件和配置；
其次代码审查这还需要花费时间去验证和部署这些代码；
代码逻辑会有争论；
问题2： 有些提交了的变更需要改进，但是原作者可能去做其他事情了。
这个问题挺常见的，原作者提交完之后就神龙不见神尾，core dev们其实对于这种按其他人提出的修改要求再提交个patchset随手把task结了的事是乐意的，但是怕侮辱了原作者（but don't want to step on toes of original submitter）。如果你认为可以帮你修改，就在commit信息里留言。 老外的心灵都是这么脆弱的么...
3. 跨多节点的orchestration是个痛苦
例如，版本升级，swift ringsync操作等等。
4. 核心基础模块已经比较完善了，但是它们所依赖的模块比如Corrosync/Packmaker仍需大量的工作，有些独立的模块开发进度太慢
5. 大多数人都是从git获取这些module，而非Forge
- 从stable分支拉取
- 通用的对于稳定分支打补丁的策略
- 如果仅是针对当前版本，只提交到master分支，如果影响到先前的稳定分支，那么做backport。目前，大多数的提交都backport到了以前的稳定分支。
- 如果你不确定，代码审查者会提醒你的
6. 某一个新变更导致stable分支无法正常工作
- 用CI来避免
- 添加新的builder来改进
7. 包管理
有一般的开发者/用户选择自己打包，另一半使用Rethat/Canonical官方源提供的包
那么是否可以在puppet modules里使用类似UID的方式来管理这些包。
Topic 4 What is missing from Puppet for Openstack? What do you want to see?
1. 初学者如何入门用puppet部署Openstack
入门手册马上就要出炉了，各位耐心等待。
2. 缺少Trove module
Emilien正在为此努力，第一版已经在会后发布了。
3. 完善bug追踪管理
有许多bugfix没有在launchpad上记录
4. 将一些部署测试和集成测试作为gate check的一部分
- 每个模块的rspec测试并不能满足发现类似于“neutron module测试没通过是因为nova module的变更引起”的错误
- 需要借助类似于packstack或者puppet_openstack_builder的工具来构建多OS的测试环境
5. 我们如何使用Puppet将线上环境从H版升级到I版本？
这个问题产生了比较多的讨论，有些开发者认为这个并不能单单靠puppet来完成，puppet能做的是包的升级，配置文件的变更，服务的启停，数据库表结构的更新等，多于节点间的变更顺序需要借助orchestration工具来做。对于如何升级的文档，首先Openstack各项目就没有明确的文档，所以puppet-openstack社区来做这事情需要从头开始，目前缺乏有效的工具，工作流程和实战经验了。并且不同的部署架构决定了不同的变更流程。我总结一下，目前还没有现成的工具来做到自动化地完成大版本的升级。不过有开发者表示开始着手研究基于puppet来完成Openstack大版本升级的解决方案了。
6. Launchpad blueprint 将会被puppet-specs替代
7. 在同个puppetmaster上使用不同版本的puppet modules
已经有人开始做这个事了：
http://docs.puppetlabs.com/puppet/latest/reference/environments.html
https://github.com/adrienthebo/r10k
End
本次puppet用户组会议的小结到此结束，用户组会议对于参与的双方来说都是受益匪浅：用户提出了自己的迫切需求和实际部署时遇到的困难，开发者们掌握了用户的确切需求，在定制下一个里程碑时就会有所着重，有针对性地开发新特性，修复bug, 对逻辑进行重构优化等等。
本次会上所收集到的几个重点需求将会在puppet-openstack developer design summmit中进行讨论，我会在下一篇博文中详细说明puppet-openstack社区在Juno release中的主要方向和工作重心。