Upgrade Openstack From Grizzly To Icehouse

首先,我们在Meetup的时候介绍过升级,请看这里的Session 3。说到升级,想起Paris summit的一个视频:Upgrading in Place from Grizzly to Icehouse: A Cautionary Tale,具体说什么没啥印象了,只记得里面那句吐槽:one developer, two weeks,事实证明不可能那么快= =

网上有很多种升级方案,例如RDO的分类就很不错。我们这边的环境对cloud的可用性要求不高,只要已经部署好的VM不受影响,可以接受较长时间不部署/管理虚拟机,所以我们最终选择了pdf里的方案一,就是controller原地升级,其实最后我们觉得换controller也不错…能降低点风险,还好升级时用方案一没遇到太多问题。

升级第一关就是db migration了,理论上来说上游代码里会考虑到升级的问题,每步db migration应该都在代码里面。其实这里还是有些问题的,我们有自己的改动,要先downgrade放弃自己的修改再upgrade,我们旧版上所有代码改动都先放弃了。。

首先就是grizzly的keystone client不支持降级(db sync指定版本),这个很好解决,改改代码咯。还有icehouse的nova db migration只支持从H版升上来,解决办法就是从H版把从G升到H的代码搞过来。。

难点在于neutron的db migration。I版的neutron经过重构,有了ml2 plugin,我们db sync之后还需要用官方提供的migrate to ml2的脚本来改数据库,以支持ml2 plugin。H版的neutron在建VM的时候会把host和port插入portbindingports表,migrate to ml2脚本就会从这个表读数据并插入到ml2_port_bindings表里,network segment的信息是由ovs_network_bindings表搞出来的。(待补充)。。

下面问题来了,portbindingports是H版才有的表,G版根本没有啊,从grizzly升上来也不会建这个表,这样migrate to ml2就会有问题。不过用ovs plugin跑起来没啥问题…最终我们的办法是在db sync之后,migrate to ml2之前把host和port插入进去,这样看起来数据ok!网上没搜到这种问题,很奇怪。还有I版用ovs plugin的时候,如果是手工建的port,neutron不会插入到portbindingports里,migrate to ml2就不会插入ml2_port_bindings表里,但是ml2 plugin会把这种port插入ml2_port_bindings。Anyway,我们最后也把这种unbound的port都插入进去了。

以上就是db migration的问题,我们在测试升级和实际操作的时候还遇到一些问题。

  1. mysql备份出来的sql,注释的地方也是有用的,不能随便删掉。

  2. 更新包的时候有些包没有依赖,不会自动更新,要手动搞。

  3. neutron agents由fqdn改成hostname,要删掉inactive的那些(这个文档也写了)

  4. 太多坑了= =!

我们整个升级用时是估算时间*2…

下次升级一定要准备更充分一点,估计是升到Kilo或者Liberty了…最好neutron的代码也有人认真看看。其实I版上游的代码还有挺多bug的,要是有能力的话有很多机会贡献代码= =…

研究升级方案时发现有好多好多可以学的东西啊~之前一直有其他需求,没空搞升级,终于在年前搞定这件大事了。(似乎还有坑没发现T_T)


comments powered by Disqus