Puppet Openstack Mitaka Design Summit小结

Puppet Openstack Design Summit小结

 

经过Puppet Openstack社区的不断努力，Puppet Openstack社区目前提供的Official Modules已经成熟，直接被用于Mirantis Fuel，Redhat PackStack等主流的部署工具中。

因此从Juno版本开始，社区的重心逐渐地转移到如何提供更全面的测试，如何抽取公共库以及规范架构等等代码的优化工作上。

 

本次Puppet Openstack Work Session放在古色古香的Aoi会议室举行，由于参会人员较多，地板上也坐满了人。由于议题数量较多，每个议题的时间较长，破天荒地被拆分为三场，主要讨论以下问题：

 

   1. init类的重构

 

为了向后兼容大量的废弃配置选项以及支持不断增长的新配置选项，当前的init.pp类越来越臃肿，这对于代码维护和理解带来了困难。最终得出解决方法概括来说有以下点：

       - 将所有配置选项根据类型拆分为子类

       - init类使用include子类来实现调用

       - 不破坏原有接口

       -  定期清理用于向后兼容的代码（就像清理草坪）

 

   2. 增加管理定制化参数的方法

 

会议现场有人提出了每个项目为了支持新参数而在不停地更新module，需要有一种方法能够在不改动module层的基础上，通过在hiera层面来应对此挑战，PTL提到了当前的module::config已经能够很好支持此需求。这个重要feature最初是由UnitedStack贡献的，目前puppet-murano外，其他二十多个module均已支持定制化参数。

 

                                      图为 PTL Emilien在谈及module::config的代码

 

3.处理客户端的warning级别输出

 

由于在某些情况下，client端会输出一些warning级别的日志，然而puppet当前的解析输出机制（不区分stdout/stderr）并不支持此类场景。已有新patch提交到了puppet-openstacklib公共库项目，方法是通过正则匹配的方式来只过滤掉warning信息，仍会捕获error级别的输出。但这个问题仍然治标不治本，由此引出了下个议题。

 

4.扩展性问题 Ruby库 vs OSclient

 

每场 work session的时间是40分钟，而大家在这个问题上争论非常激烈，以至于连10分钟的中场休息也没有放过，这个话题足足讨论了30分钟。

简单介绍该议题的上下文：当前puppet调用各服务的API接口获取资源信息是通过custom resource type和facter来获取的，这些自定义的脚本又是通过调用python-openstackclient的命令行接口来实现以上功能。

在最近的ML讨论中，由Mirantis的Sergey发现puppet-neutron模块在某种情况下，在议题3中我们已经知道Puppet傻傻分不清楚标准和错误输出，导致抓取了错误的输出信息，从而获取了不正确的net id。

说实话，社区在这个问题上已经在ML和IRC上经过了多届拉锯战般的讨论：要不要自己造个轮子，写个Ruby版本的SDK。

其实在OSclient之前，大家饱受使用各项目Client的痛苦（接口和输出不统一），于是由原Puppetlabs公司的美女工程师Crinkle发起，（索要照片请私信）写了一个Ruby SDK。但不久之后，OSClient横空出世，这个项目就被雪藏了。但现在大家发现在ruby中使用osclient的命令行接口还是比较坑爹的，于是又怀念起纯正血统的ruby SDK。

那么既然决定要干：大家又开始讨论应该怎么做，怎么利用现有的项目资源，如何使用现有的公共库等等各种问题（一言蔽之，怎么偷懒）。最终的结论是这样的：

    It would be really really cool to have a ruby sdk for OS.

 

持反对意见者稍加润色以表示他们的怀疑态度：

    It would be really really cool to have a (good) ruby sdk for OS

 

5.增加健康检测module

   这是一个比较有意思的项目，例如我们希望能够在Puppet将服务启动或者重启后，有一个机制可以确认API服务是正常运行的。比如手动使用一个简单的curl命令，判断web应用的状态返回码。因此，有些工程师在一些类中添加了监控检测的代码来做这样的事情。不过都是一些松散分散在各个项目中的代码，因此社区这次把健康检测抽象成一个独立的module，提供标准的class和define接口，方便代码复用和持续地优化。

 

6.在*_config resource type中添加处理弃用配置选项的功能

 

这个topic属于一个新特性的讨论，例如，在Kilo版本开始，rabbit_hosts参数从DEFAULT section中移动到了slo_messaging中去。因此，我们希望通过以下格式将neutron中关于rabbit_hosts的新旧参数都集中管理起来：

 

 neutron_config { 'oslo_messaging/rabbit_hosts': old_key => 'DEFAULT/rabbit_hosts', value => $value}

 

由于属于大家都喜闻乐见的特性，无人持异议，并且该议题的提出者clayton将如何实现的细节都写到了etherpad上（应放在puppet-specs里讨论实现的细节）。PTL戏称，你这是要让大家在etherpad给你+1的节奏嘛？一时间会议室里充满了快活的空气。

 

其他还有一些小的议题，例如PTL跪求更多的人参与到贡献和审查代码的工作中来（因为现在参与人员庞大，core member不够用了，每天都有审查不完的patch），还有当前puppet-ceph模块的进展和roadmap等等，这里就不再展开介绍了

 

通过这几届的design summit来看，Puppet Openstack社区已经完成了从无到有，从有到好的阶段，在完成了众多基础模块的开发以及公共库模块的抽取工作之后，社区当前的目标是进一步完善每个模块，确保可以处理各种异常情况，为终端用户或其他开发人员提供更好的部署服务。

 

UnitedStack Devops team在最近发布的Liberty版本中对Puppet Openstack社区做出了积极贡献，排名第四。在随后的Mikata Release开发中，我们会继续保持对Puppet Openstack社区的积极参与。