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

 

 

 

posted @ 2015-12-11 15:15 牛皮糖NewPtone 阅读(...) 评论(...) 编辑 收藏