HK Openstack Summit 归来有感

bobpxp

　　4天的Icehouse openstack Summit终于结束，从香港又回到了北京，我们的产品反响相当不错，吸引了很多的注意力和商谈。可是实际上我最近过得很憋屈，心灰意冷，没有了当初那么拼命的动力。
　　先不说这些闹心的，谈谈我从summit归来的感受吧。
　　首先，最让我受到挫折的是英语听力。在会场上，你会遇到各国人，他们并不是使用那么纯正的英语，对于我来说，很难跟上他们的交谈，尤其是在design summit上。我一直对自己的英语很自信，之前做过一些技术书籍的翻译，每天和老外在IRC,ML上交流，没有任何阻碍，结果面对面的交流就歇菜了，这对我的打击好大，这次回来之后，得好好加强一下这个方面的练习。
　　其次，给我印象最深的是由HP和RedHat发起的一个由TripleO+Ironic+Heat以及相关孵化项目组合而成的庞大体系在本次summit上浮现出来，该项目旨在物理资源和虚拟资源生命周期管理入口的统一，未来可以通过Openstack的API实现对这两种资源的统一管理。虽然目前有大量的解决方案，例如Cobbler,Foreman,cowbar等等，但假如社区也开始做这个事情了，估计未来还是得走上统一的道路。不得不说Redhat和HP的实力强大，背后拥有大量的core devs和众多项目的PTLs，在把握项目的发展方向上拥有明显的话语权，其他众公司只能望尘莫及了。在我参加的Puppet-openstack design summit上，redhat的packstack的作者谈论了大约近1个小时的TripleO在和puppet整合上遇到的问题，可见其影响之大了。
　　在谈谈puppet-openstack社区的讨论吧，先说点有趣的，刚开始我们并没有拿到场地，直到7号puppetlabs的人才在ml里发通知，说终于找到一个会场了，我以为可能去的人很少，结果我们刚开始从两张大圆桌，到后来人太多，把两张圆桌去掉，围上了满满的一屋人。前面的议题是关于社区管理上的细节，我提了两个topic，一个关于项目管理，一个是文档加强，没啥好说的，这里就不提了。最主要的两个topic是puppet-openstack module的弃用和新module puppet-common的创建：目前我们在使用的puppet-openstack模块变得越来越臃肿，使得它不再那么灵活，因此社区希望采用新的方案来替代它，旧的module会在下一个openstack release中被弃用；建立puppet-openstack-common的目的是代码重用，把每个module冗余的代码都提取出来，作为一个公共的库来使用，之前一直在ml上提起，这次终于开始动手了。
　　
　　对了，我还去了Canonical的展台，尝试使用了Juju，他们将其定位为orchestration，类似于heat，UI的拖动设计得不错，对于普通用户来说非常友好，但在后端的设计上还远远不够，比如我尝试了使用部署ceph的功能，点击配置，可以看到每个功能(称为hook)的源码，例如，install对应的就是一行bash语句:apt-get install ceph，启动服务也是类似，如果我希望每次安装最新版本的呢，或者我希望即使source中有最新的包，我也不希望去安装，如何保证？ 收敛性和幂等性又如何保证？ 都需要自己去写代码来保证，这对于开发效率来说，非常低下。有一点值得一提，后端的功能可以用shell,python,ruby等各种语言来实现，没有自己的DSL，这点上来说，既有好处，也有坏处，我目前更倾向于dsl，因为我现在不再是当年的学生时代，想写什么就写什么，不用考虑后期维护的成本。目前在UOS中，我维护了近60个puppet module，数十万行代码，如果每个module都使用不同的语言开发，这对于后面想要接管我工作的孩子来说，简直是个梦靥。
　　最后再上一张Openstack Foundation发布的数据统计图（http://www.slideshare.net/openstack/openstack-user-survey-october-2013），puppet在Openstack部署工具的占有率上遥遥领先。而且第二名还是devstack，这个仅适用于部署开发和测试环境，如果是严肃的生产环境，devstack并不适合。（但我了解到国内真有公司拿devstack一包装，就拿去给人部署的情况）