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版本,這是值得考慮的一個問題，對於私有云，我們其實並不需要最新的版本，只需要符合自己的需求就可以了。
在目前版本滿足需求的情況下，我們可以把更多的精力放在調優和穩定性優化上面。