共計 3826 個字符，預計需要花費 10 分鐘才能閱讀完成。
這篇文章主要介紹 OpenStack 如何處理 BUG，文中介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們一定要看完！
一. 發現 Bug:
?Nova 中的虛擬機軟刪除 (soft-delete) 功能，是指在一段時間內，僅將數據庫中的某虛擬機記錄做一個標記 (status= SOFT-DELETE)，然后將虛擬化平臺(kvm 等) 中對應的虛擬機實例置為關機狀態，當超過某一時間段后才將虛擬機實例真正刪除; 該功能為云平臺用戶提供了“后悔時間”，可以在一定程度上挽回誤操作。默認情況下，軟刪除功能是關閉的，其開啟方式是在 nova 配置文件中添加 reclaim_instance_interval 選項，并將其值設置為 后悔時間 的毫秒數。
?在描述具體 Bug 前，需要對 openstack 中的用戶管理方面的基本概念簡單介紹一下。
?上圖是 openstack 用戶模型的簡化版本，為了便于理解將不屬于 keystone 管理的 quota 也拿了過來。
?Bug 就與軟刪除相關。具體場景是這樣的：假設 OpenStack 中有兩個項目和兩個用戶: 普通項目 A 其用戶 a, 管理員項目 Admin 其用戶為 admin(用戶管理相關概念可以查閱 keystone 文檔)，用戶 a 不慎將自己的一臺虛擬機刪除了，這時求助系統管理員看看有沒有辦法恢復，好在系統開啟的軟刪除功能，而且被刪除的虛擬機還在可回收的時間范圍內，這時管理員便以 admin 的身份登錄系統，為用戶 a 恢復了虛擬機，但是細心的管理員卻發現了一些不對：其 Admin 項目下并沒有任何虛擬機，但是其配額卻被使用了，難道這和剛才的操作有關？再來重試一下：普通用戶刪除虛擬機，admin 用戶來為其恢復，這時配額又發生了變化，果然如此：被恢復的虛擬機的配額錯誤的添加到了 Admin 項目下。該 Bug 在最新的 kilo 版本中仍然存在，感興趣的同學可以實驗一下。
二. 定位 Bug:
?發現了 Bug 的存在，那就更進一步，到代碼中找一下原因吧。
?如何確定問題代碼的位置呢？這需要對 Nova 的項目結構有大體的了解，我們來簡單了解一下：
?上圖是 nova 架構的極簡版本，與本問題無關的組件都沒有畫上去，恢復虛擬機的操作過程大致是這樣：
nova api 接收到用戶請求，到數據庫中查詢虛擬機詳情，將該虛擬機所在的主機、名稱等數據發送到消息隊列中;
nova compute 服務在監聽到相關消息后，開始執行具體操作，將虛擬機在數據庫中的記錄做些調整，調用底層驅動恢復虛擬機。
?既然軟刪除的功能層面沒有任何問題，虛擬機的刪除和恢復過程都很順利，可見不會是驅動的問題，順著 API 層的代碼調用往下找，很快就可以定位了。直接看出問題的代碼片段：
def restore(self, context, instance):
# 該代碼做了刪減
flavor = instance.get_flavor()
# 獲取 quotas 對象
num_instances, quotas = self._check_num_instances_quota( context, flavor, 1, 1)
self._record_action_start(context, instance, instance_actions.RESTORE)
try:
if instance.host:
instance.task_state = task_states.RESTORING
instance.deleted_at = None
instance.save(expected_task_state=[None])
self.compute_rpcapi.restore_instance(context, instance)
else:
instance.vm_state = vm_states.ACTIVE
instance.task_state = None
instance.deleted_at = None
instance.save(expected_task_state=[None])
# 更新 quotas
quotas.commit()?上面的這段代碼就是 API 層面上進行虛擬機回收的主要方法，可以看到其中有明顯的配額操作(quotas)，在解讀這段代碼前有必要先對 nova 中 context 的概念做個簡介。不僅是 nova，在 openstack 其他項目中都隨處可見這個 context，它是一個包裝了用戶請求信息的對象，包含用戶的項目和認證信息等，通過它可以簡便的進行各項目之間的 API 調用和用戶信息的查詢，API 服務接收到用戶的每一次 HTTP 請求，都會創建一個新的 context。
?回到這段代碼，我們重點關注對 quotas 所作的操作：在方法的第二行，通過了一個方法獲取了 quotas，有在方法的結尾執行了 quotas.commit()，能夠獲取到的信息不多，我們再看一下獲取 quotas 的方法：_check_num_instances_quota
# 這里只截取一部分
def _check_num_instances_quota(self, context, instance_type, min_count,
max_count):
req_cores = max_count * instance_type[vcpus]
vram_mb = int(instance_type.get( extra_specs , {}).get(VIDEO_RAM, 0))
req_ram = max_count * (instance_type[ memory_mb] + vram_mb)
try:
quotas = objects.Quotas(context)
quotas.reserve(context, instances=max_count,
cores=req_cores, ram=req_ram)
...
return max_count, quotas?這里可以看到獲取 quotas 的過程：通過當前的 context 創建 quotas 對象，并且執行了 reserve 操作; 我們知道 context 是由 HTTP 請求而來，里面保存的是發請求的用戶的信息，所以這里的 quotas 對象的“所有者”也就是 context 中的用戶。
?結合 Bug 發生的場景來看：管理員還原用戶 a 的虛擬機，發請求的是管理員，當前 context 中記錄的是管理員的信息，這里的 quotas 理所當然的就是管理員的，然后操作了用戶 a 的虛擬機，更新的卻是管理員的 quotas。嗯，真相大白！
三. 修復 Bug:
?Bug 的原因是獲取的 quotas 并不屬于期望的用戶，但是直接修改 context 顯然不合適(會影響后續的操作)，先了解一下 quotas 對象自身吧：
class Quotas(base.NovaObject):
# 部分代碼
def __init__(self, *args, **kwargs):
super(Quotas, self).__init__(*args, **kwargs)
# Set up defaults.
self.reservations = []
self.project_id = None
self.user_id = None
self.obj_reset_changes()
...
def reserve(self, context, expire=None, project_id=None, user_id=None,
**deltas):
reservations = quota.QUOTAS.reserve(context, expire=expire,
project_id=project_id,
user_id=user_id,
**deltas)
self.reservations = reservations
self.project_id = project_id
self.user_id = user_id
self.obj_reset_changes()
def commit(self, context=None):
if not self.reservations:
return
if context is None:
context = self._context
quota.QUOTAS.commit(context, self.reservations,
project_id=self.project_id,
user_id=self.user_id)
self.reservations = None
self.obj_reset_changes()?注意看 reserve 方法的參數，默認為 None 的 project_id 和 user_id，這正是改變 quotas 屬主的方便入口！
?修改后的代碼這里就不貼了，感興趣的同學可以到這次提交中看：Code Review
四. 代碼提交和 Review:
?openstack 社區有著整套項目管理流程，這里有一張圖能夠較詳細的描述工作流程：
?由圖可見 bugfix 是其中最簡單的流程。
以上是“OpenStack 如何處理 BUG”這篇文章的所有內容，感謝各位的閱讀！希望分享的內容對大家有幫助，更多相關知識，歡迎關注丸趣 TV 行業資訊頻道！
