OpenStack如今已成為開源云平臺中的明星項目，得到廣泛關注。OpenStack的優秀出眾依賴于眾多開發者的努力，在享受其帶來的便利與快捷的同時，為其做一份貢獻也是一個開發者的義務。在前段時間的OpenStack的測試過程中，我發現Nova項目中的一個Bug，于是向社區提交了Bug報告，并提交代碼修復了該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架構的極簡版本，與本問題無關的組件都沒有畫上去，恢復虛擬機的操作過程大致是這樣：

1. nova api接收到用戶請求，到數據庫中查詢虛擬機詳情，將該虛擬機所在的主機、名稱等數據發送到消息隊列中;
2. 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。嗯，真相大白!

#p#

三.修復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 貢獻您的代碼。另外需要注意一點，在國內向社區提交代碼，經常會因為網絡問題導致無法提交，幸好找到了大牛的博客介紹了該類問題的解決辦法。  修改完代碼的單元測試和pep8本地測試當然不能少，早就知道社區對單元測試要求很嚴格，這次才真正領教了，三行代碼的修改，單元測試卻寫了30 行，review期間多次因為單元測試的問題重提代碼(哭)。社區里面的開發者，尤其是項目的core，對待項目有著像對自己孩子般的認真與細致：他們會在一個自己根本不會在意的地方提醒你、面對當前的問題他們會延伸的考慮類似的問題。他們的態度讓我首先感受到的吃驚，然后是敬佩!

經歷八次review、歷時近一個月，我的代碼總算是入庫了!希望我的這篇記錄能對你有幫助。

感謝休倫公司技術總監 孫琦 提供的英文支持，社區大牛Alex Xu給出的修改建議。

Launchpad上面的bug提交： Abnormal changes of quota usage after instance restored by admin

代碼審查過程： Fix abnormal quota usage after restore by admin

Git@OSC中的代碼： Fix abnormal quota usage after restore by admin

博文出處：http://my.oschina.net/zyzzy/blog/509315

關于OpenStack

OpenStack是一個由NASA(美國國家航空航天局)和Rackspace合作研發并發起的，是一個開源的云計算管理平臺項目，由幾個主要的組件組合起來完成具體工作。OpenStack支持幾乎所有類型的云環境，項目目標是提供實施簡單、可大規模擴展、豐富、標準統一的云計算管理平臺。

OpenStack除了有Rackspace和NASA的大力支持外，還有包括戴爾、Citrix、Cisco、Canonical等重量級公司的貢獻和支持，致力于簡化云的部署過程并為其帶來良好的可擴展性。