Juno Puppet Opertaors Meetup小结

今年五月刚结束的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中的主要方向和工作重心。