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社区的积极参与。