Openstack 自动化部署puppet代码管理

Openstack发展的很快,6个月就会release,每次release后不免升级到最新的版本。自动化部署是绕不开的一个问题。目前自动化部署使用的是puppet脚本,那么什么策略管理本地的自动化部署脚本一直困扰着我们。


我们的puppet代码是从PuppetLabs的E版本开始的,当时只支持Ubantu,而且bug很多,我们在自己的分支上fix了很多bug。然而,社区发展Release很快,出了F版本以后,我们puppet代码在自己的分支中实现了F版本的部署,在F版本的时候,我们还在自己的分支中支持了CentOS。后来刚做完,G版本出了,于是又开始对G版本进行自动化部署。期间还走了弯路,要在CentOS上支持python2.7(噩梦般的回忆... 重新打几百个包)。 10月份社区又出了H版本,于是我们从12月底开始又要支持Havana的自动化部署。。。


其实自动化部署仅仅是很小的一部分,但是却花费了我们很多精力。原因如下:
1. 在E,F版本时,puppetlabs的代码存在很多bug,我们在本地修改后没有合入upstream。
2. 我们自己修改的support CentOS,已经和社区越走越远。

3. 我们支持CentOS时,RDO还发展不成熟,我们需要自己打RPM包。

4. 自己走了一些弯路。。。



自动化部署的代码基本上可以分为3部分:
#1. Openstack核心功能部分。
#2. DB和MQ集群部署部分。
#3. 平台监控,定制功能部分。


那么每次release需要更新的部分主要在#1中。在升级H版本时,我们决定放弃我们维护的本地分支,使用PuppetLabs最新的代码,并采取以下策略应对以后puppet升级问题:
1. 每次社区release新版本,3-6个月后,升级Openstack核心功能的自动化部署相关代码。
2. 对于#2和#3部分自动化部署代码,不做修改,仅进行功能测试。


使用这样的策略,我们升级H版本的自动化部署代码大约需要了1-1.5人月(不包含测试)。这样的effort是可以接受的。当然我们是否真的需要升级Openstack版本,这是值得考虑的一个问题,对于私有云,我们其实并不需要最新的版本,只需要符合自己的需求就可以了。
在目前版本满足需求的情况下,我们可以把更多的精力放在调优和稳定性优化上面。

Openstack 自动化部署puppet代码管理

上一篇:二叉树的深度


下一篇:希尔排序(Shell Sort)