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类:

  1. 直接使用upstream的代码,并保持更新
  2. 使用upstream的代码,但只在必要时进行更新
  3. 使用upstream puppet模块和私有的composition layer
  4. 使用未修改的核心模块,但不使用puppet-openstack作为顶层的composition layer
  5. 使用定制化模块和针对特定节点的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中的主要方向和工作重心。

posted @ 2014-06-04 15:03 牛皮糖NewPtone 阅读(...) 评论(...) 编辑 收藏