Juno——OpenStack评论系列

问题导读：
1.Juno相比Icehouse有什么变化？
2.如何改善Neutron的性能？
3.Horizon有什么改进？



序言
>>OpenStack的现状

一句话概括OpenStack的现状，可谓“如日中天”。

OpenStack发展至今，已逐渐成长为云计算领域的中坚力量，无论供应商还是开发者们，对OpenStack的热情都居高不下。据统计，截至2014年8月，对OpenStack社区贡献commit或者review的人数达到了2600人/天，而在一年前，这个数字仅为现在的一半。

>>Juno版的变化

如今Juno版本已基本尘埃落定（9月4日Feature Freeze），相比较之前的版本，Juno最大的变化是带来了Sahara（旧称：Savanna），Sahara项目旨在为OpenStack用户提供一种简单、快捷地部署以及管理Hadoop集群的方案，类似于亚马逊Elastic MapReduce (EMR) 服务。

其它各个模块，其blueprint的数量都比Havana和Icehouse版本有明显减少（Neutron是个例外，提了12个blueprint，但只完成了4个，大多数没有能在Juno版完成）。这是一个可喜的变化，一定程度上体现了OpenStack的开发者们开始放慢实现新Feature的速度，开始把注意力更多地放在改Bug和Review上。从长远来看，这对OpenStack的发展是有益的。

虽然Juno版减少了新Feature的数量，但其中不乏许多有意思的提交，值得一提。这篇文章摘录了其中的一些，以郷读者。

各个模块的Features
>>结成“联盟”的Keystone

Juno版本中，Keystone最引人瞩目的一个Feature莫过于“Keystone to Keystone federation”。

这个Feature旨在让多个Keystone实例能够结成联盟，为用户提供跨云的用户认证服务，以及同质(homogeneous)的跨云服务列表。

在Icehouse版本中，我们只能在idP(identity provider)和Keystone实例之间建立信任关系。在这种模型中，云实现方只能通过单点登陆的方式来验证用户，Keystone完全信任idP，并接受他们传递过来的federated identities。但此时，一个Keystone不能信任另一个Keystone，这让跨云认证受到了很大的限制。

这个Feature看似简单，代码量也不多，但却从7月初开始，一直做到9月上旬，整整两个月有余。看起来Keystone的Core Developer们比较谨慎。这个Feature实现了OS-FEDERATION的API，从文档到controller，route，可算是非常完整的一个例子，值得一读。在这里要再次感谢对这个Feature做出主要贡献的Steve Mattinelli和Marek Denis两位大拿，他们都来自IBM。

>>令人失望的Neutron

Neutron可算是Juno版OpenStack最令人失望的模块，没有之一。最受关注的L3-HA，从3月份就开始捣鼓，至今仍未完成。

完成的4个blueprint中，3个和重构有关，分别是“Port to oslo.messaging”，“DB Migration Refactor”以及“Security group rules for devices RPC call refactoring”。

从好的方面看，Neutron在Juno版放慢了脚步，注重重构代码。从糟的方面看，这步子，实在放得过慢了。

>>高歌猛进的Ceilometer

Ceilometer在Juno版得到了长足的发展，提交通过了20个blueprint。在这些blueprint中，给我印象比较深刻的是Pradeep Kilambi(来自Cisco)提交的三个blueprint，分别是meter-fwaas、meter-lbaas以及meter-vpnaas。代码很简单，也很完整，为同学们添加自己的计量实例提供了范例。

来自Intel的Lu Lianhao完成了snmp-improvement的bp，也值得一读。

SNMP的应用非常广泛，我曾经在一些私有云的产品中看到多个SNMP实例在Ceilometer中的计量实现，包括在Horizon中的图标实现，非常完整。但是可惜目前都还没有提交到社区里来。

相信不久以后就会有。

>>提不起兴趣的Cinder

Cinder在Juno版中blueprint也很多，但我通读下来的较少，比较喜欢其中一个较为边缘的bp: “Improve taskflow logging”。这个blueprint的作者是来自Yahoo的Joshua Harlow。

在这个blueprint里，较简单地呈现了taskflow库的用法。代码逻辑实现了两个打log的方法，并将其hook在flow和task状态变化的时候。整个实现比较简洁。

这个bp本身比较边缘，但通过它我顺便了解了一下taskflow的接口和原理。taskflow是OpenStack中被多个模块使用到的类库，值得一看。

另外，我注意到99cloud的Liang Bo提交了bp: zfs-based-iscsi-san，这个patch我测试过，确实是可用的。但哥们也太懒了，单元测试都不愿意写，就这样Abandoned掉。这个bp至今未有人继续完成，实在可惜。若是有用DIY zfs的同仁，可以参考这个patch，顺便把它补完吧。

>>让人又爱又恨的Horizon

Horizon应该是提交bp最多的模块了吧？

爱之深，痛之切。这是我对于Horizon最直接的感受。Horizon发展至今，作为一个Dashboard，仍然和OpenStack的其它模块耦合紧密。一个模块出问题可能会导致Horizon整个Crash。但到目前位置，仍然没有更好的Dashboard出现，基于Horizon出自己的定制版仍是供应商们最有效率的开发模式。

在Juno中，除了为各个模块添加和完善Web UI，开发者们同样花了很多精力来完善代码。比如，来自enovance（现在应该是redhat了J）的Maxime Vidori完成了bp: jshint-codestyle，限制了JavaScript代码的写法，包括缩进、相等运算符、大括号、过滤语句、逻辑运算符的使用等等。

还有，在bp: remove-javascript-bundling中，jQuery和bootstrap的代码被整个地移除OpenStack代码库，以安装包取而代之。也算是大快人心的一个improvement。

>>变化极小的Nova

Nova不出意外地没什么新变化，实现的两个blueprint，一个是重构(Compute Manager uses Objects)，一个是数据库后向迁移(Allow DB migration backports to Icehouse)。

>>那些年我们追过的BugKeystone: LDAP问题

Bug #1222675 LDAP Identity Driver does not call delete_user or delete_group on the LDAP assignment api

Report By morgan@metacloud.com

目前Keystone最多的问题来自于Ldap，在Tags的排行榜上，Ldap常年名列第一。这大概和AD在Linux的世界里不那么流行有很大关系。这个Bug拖得实在太久，都快一年了。最郁闷的是最后它是被秒杀掉的。大家可以看看之前的改法和最后的改法。让人感慨代码行数真的不能作为评判码农的依据。非常值得一读的一个改动。感谢来自IBM的Brant Knudson。

>>Horizon和Glance: 消失的快照

Bug #1116991: horizon can't display user's snapshot images

Reported by yaguang.tang@canonical.com

这应该是Glance给我留下影响最深的Bug了（虽然最后证明它不是代码的bug，而是一个配置问题）。这个问题很容易重现，只要在Dashboard上创建一个Snapshot，然后就可以通过命令行nova image-list取到，但无法从Dashboard中看到，这对产品来说算是一个比较严重的问题。这个问题困扰我很久，最后我是通过“简单粗暴”地改代码来临时解决的。

这个不是Bug的“Bug”，从被最先提出（后续还陆续被report了好几次），到最后被证明是一个Glance的配置问题，历经整整11个月，影响既广且久。甚至于时至上个月，仍有同学在和我讨论OpenStack问题的时候提到这个问题，说不知道怎么解L。

回顾来看，这个Bug实在不该拖着么久的，因为其逻辑并不算复杂。虽然它刚开始被开到Horizon那边去，但其实很容易定位到Glance上，因为Horizon只是简单地call了glance image-list而已。可能是，关注Glance的人太少了吧，开发者的热情和开源产品的成熟度成反比，这是一个很现实的问题。

>>Neutron: DHCP问题和MTU问题

Bug #1192381: dhcp dnsmasq lost port in host config file

Report By wu.wenxiang@99cloud.net

我想所有在Grizzly版玩过Neutron（那时好像还叫Quantom）的兄弟，都应该对这个Bug有印象。我遇到它时，已经有99cloud的兄弟report过了。这个Bug会导致虚机拿不到地址，并且重启虚机仍不能fix。它的Impact不可谓不大，也很容易重现，是一个Critical的Bug，但居然花了整整大半年才Fix（半年对于其它Bug来说可能没有那么难接受，但IaaS云中的网络问题是足以一票否决其产品的）。感谢来自Redhat的“牛B哥”：Maru Newby J

好吧，Neutron实在是有令人失望的传统，顺便吐糟。

OVS/GRE的MTU问题是另一个广为流传的故事。当年测试组的兄弟Report Windows Instances不能访问www.baidu.com但可以访问www.163.com的时候，我们心中有一万只神兽奔腾着呼啸而过。最后各种抓包各种Research，定位到MTU上，GRE的本质是将二层网络跑在三层上，所以终端用户收到的IP包和网络上真实传输的IP包之间存在46位的差值，20+8+18（IPv4-Header + GRE-Header + Ethernet-Header），如果计算节点的MTU是1500，那么对应到终端用户的Instance，MTU只能是1454。这个问题有两个解法，一是把计算节点网口上的MTU值该大，二是把Instance上的MTU改小。

>>来自国内的贡献

现在Mirantis的贡献度排名默认采用Review次数，这还是挺合理的。

Review次数+代码贡献量+Bug提出数量，应该能体现比较真实和公平的排名。

国内的兄弟挺不容易，很多兄弟需要颠倒着时差来commit/review代码，还要会熟练地以各种姿势翻墙。

尤其要表扬的是华为的同行们，无论Review数量还是代码贡献量，都在前15名。接下来比较突出的是99cloud, EsayStack和UnitedStack。99cloud和EasyStack是除huawei以外一直坚持社区代码贡献的国内团队，代码贡献是劳心劳力以及烧钱的事，坚持至今非常不易，且行且珍惜吧。UnitedStack在Juno版本里review较多，commit则很少，看起来他们更专注于自己的产品了。很希望尽快看到他们更好的产品。

###################################################
本文转自：http://mp.weixin.qq.com/s?__biz= ... d9c9998d3cf4bce3#rd