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版本,这是值得考虑的一个问题，对于私有云，我们其实并不需要最新的版本，只需要符合自己的需求就可以了。
在目前版本满足需求的情况下，我们可以把更多的精力放在调优和稳定性优化上面。