這是 OpenStack 實施經驗分享系列的第 10 篇。
是軟件就會有 bug，OpenStack 也不例外，只要用它就一定會遇到故障。Troubleshooting（故障排除）是運維 OpenStack 等開源項目的重要技能，遇到問題后一定要借助社區的力量定位、搜索、分析並解決問題。
下面 CloudMan 將分享一個真實的案例，還原當時 Troubleshooting 的過程，希望能給大家一些啟發。
問題描述
某天客戶的 OpenStack 突然全線癱瘓：任何操作都無法正常完成，一直處於正在執行狀態，界面上也不報錯，就是無法完成操作。
問題分析
這是一個全局性的問題，首先查看 nova 日志，無報錯，再看 MySQL 和 RabbitMQ 日志，在 RabbitMQ 中發現大量重復報錯：
一直報 reply_529af7a7c3784c2d9dc5e72c603024a5 這個 exchange 找不到。 這些 reply_XXX 的都是 OpenStack 自己維護的，之前運行得好好的，為什么突然找不到，應該是發生了異常，跟配置沒有關系，估計是 bug。
先 google 一下吧。搜索技術問題，google 是首選，翻不了牆就用 bing，度娘嘛還是讓她專注中文吧 :-)
這里貼出 bing 的搜索結果：
看上去第二個比較靠譜，點進去發現跟我們的情況完全一樣，而且還提到一個相關 bug。
瀏覽一下 bug 的內容，確實是我們遇到的問題，這是一個 oslo.messaging 的 bug，而且已經 fix 了。
因為客戶 OpenStack 版本是 kilo, 所以點擊 kilo 對應的 review 鏈接看看 fix 都修改了哪些地方。
一共改了兩個文件，點開 amqpdriver.py 的鏈接，可以看到 diff。
對比客戶系統 /usr/local/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py 文件內容，確實是 fix 之前的版本。
問題確定了，解決辦法也有了：更新 olso.messageing 包。
解決問題
OpenStack 的源代碼是在 github 上維護的，每個模塊有自己的 repository。 oslo.messageing 的項目主頁是 https://github.com/openstack/oslo.messaging
因為我們目前的版本是 kilo，所以要找 oslo.messaging 在 kilo 上的最新版本。
在 Tags 中，我們看到有 kilo-eol，eol 的意思是 “end of life”，是 kilo 的最終版本了。
可以再次確認，kilo-eol 確實包含了我們想要的 fix。后面的工作就很直接了：
-
下載 oslo.messaging 代碼庫。
-
安裝 kilo-eol 版本。
-
重啟相關 OpenStack 相關服務。
下節我們會詳細討論如何更新 OpenStack 組件。
由於 oslo.messaging 是基礎組件，幾乎所有服務都會用到，所以不得不更新每一個節點並重啟 OpenStack。工作量雖然大些，但問題終於解決了。
