OpenStack如今已成為開源云平臺中的明星項(xiàng)目，得到廣泛關(guān)注。OpenStack的優(yōu)秀出眾依賴于眾多開發(fā)者的努力，在享受其帶來的便利與快捷的同時，為其做一份貢獻(xiàn)也是一個開發(fā)者的義務(wù)。在前段時間的OpenStack的測試過程中，我發(fā)現(xiàn)Nova項(xiàng)目中的一個Bug，于是向社區(qū)提交了Bug報告，并提交代碼修復(fù)了該Bug，從提交報告到代碼入庫經(jīng)歷近一月，下面重現(xiàn)整個過程。

一.發(fā)現(xiàn)Bug:

Nova中的虛擬機(jī)軟刪除(soft-delete)功能，是指在一段時間內(nèi)，僅將數(shù)據(jù)庫中的某虛擬機(jī)記錄做一個標(biāo)記 (status='SOFT-DELETE')，然后將虛擬化平臺(kvm等)中對應(yīng)的虛擬機(jī)實(shí)例置為關(guān)機(jī)狀態(tài)，當(dāng)超過某一時間段后才將虛擬機(jī)實(shí)例真正刪除;該功能為云平臺用戶提供了“后悔時間”，可以在一定程度上挽回誤操作。默認(rèn)情況下，軟刪除功能是關(guān)閉的，其開啟方式是在nova配置文件中添加"reclaim_instance_interval"選項(xiàng)，并將其值設(shè)置為"后悔時間"的毫秒數(shù)。

在描述具體Bug前，需要對openstack中的用戶管理方面的基本概念簡單介紹一下。

上圖是openstack用戶模型的簡化版本，為了便于理解將不屬于keystone管理的quota也拿了過來。

Bug就與軟刪除相關(guān)。具體場景是這樣的：假設(shè)OpenStack中有兩個項(xiàng)目和兩個用戶:普通項(xiàng)目A其用戶a,管理員項(xiàng)目Admin其用戶為 admin(用戶管理相關(guān)概念可以查閱keystone文檔)，用戶a不慎將自己的一臺虛擬機(jī)刪除了，這時求助系統(tǒng)管理員看看有沒有辦法恢復(fù)，好在系統(tǒng)開啟的軟刪除功能，而且被刪除的虛擬機(jī)還在可回收的時間范圍內(nèi)，這時管理員便以admin的身份登錄系統(tǒng)，為用戶a恢復(fù)了虛擬機(jī)，但是細(xì)心的管理員卻發(fā)現(xiàn)了一些不對：其Admin項(xiàng)目下并沒有任何虛擬機(jī)，但是其配額卻被使用了，難道這和剛才的操作有關(guān)?再來重試一下：普通用戶刪除虛擬機(jī)，admin用戶來為其恢復(fù)，這時配額又發(fā)生了變化，果然如此：被恢復(fù)的虛擬機(jī)的配額錯誤的添加到了Admin項(xiàng)目下。該Bug在***的kilo版本中仍然存在，感興趣的同學(xué)可以實(shí)驗(yàn)一下。

二.定位Bug:

發(fā)現(xiàn)了Bug的存在，那就更進(jìn)一步，到代碼中找一下原因吧。

如何確定問題代碼的位置呢?這需要對Nova的項(xiàng)目結(jié)構(gòu)有大體的了解，我們來簡單了解一下：上圖是nova架構(gòu)的極簡版本，與本問題無關(guān)的組件都沒有畫上去，恢復(fù)虛擬機(jī)的操作過程大致是這樣：

1. nova api接收到用戶請求，到數(shù)據(jù)庫中查詢虛擬機(jī)詳情，將該虛擬機(jī)所在的主機(jī)、名稱等數(shù)據(jù)發(fā)送到消息隊(duì)列中;
2. nova compute服務(wù)在監(jiān)聽到相關(guān)消息后，開始執(zhí)行具體操作，將虛擬機(jī)在數(shù)據(jù)庫中的記錄做些調(diào)整，調(diào)用底層驅(qū)動恢復(fù)虛擬機(jī)。

既然軟刪除的功能層面沒有任何問題，虛擬機(jī)的刪除和恢復(fù)過程都很順利，可見不會是驅(qū)動的問題，順著API層的代碼調(diào)用往下找，很快就可以定位了。直接看出問題的代碼片段：

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層面上進(jìn)行虛擬機(jī)回收的主要方法，可以看到其中有明顯的配額操作(quotas)，在解讀這段代碼前有必要先對nova 中"context"的概念做個簡介。不僅是nova，在openstack其他項(xiàng)目中都隨處可見這個"context"，它是一個包裝了用戶請求信息的對象，包含用戶的項(xiàng)目和認(rèn)證信息等，通過它可以簡便的進(jìn)行各項(xiàng)目之間的API調(diào)用和用戶信息的查詢，API服務(wù)接收到用戶的每一次HTTP請求，都會創(chuàng)建一個新的context。

回到這段代碼，我們重點(diǎn)關(guān)注對quotas所作的操作：在方法的第二行，通過了一個方法獲取了quotas，有在方法的結(jié)尾執(zhí)行了 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的過程：通過當(dāng)前的context創(chuàng)建quotas對象，并且執(zhí)行了reserve操作; 我們知道context是由HTTP請求而來，里面保存的是發(fā)請求的用戶的信息，所以這里的quotas對象的“所有者”也就是context中的用戶。

結(jié)合Bug發(fā)生的場景來看：管理員還原用戶a的虛擬機(jī)，發(fā)請求的是管理員，當(dāng)前context中記錄的是管理員的信息，這里的quotas理所當(dāng)然的就是管理員的，然后操作了用戶a的虛擬機(jī)，更新的卻是管理員的quotas。嗯，真相大白!

#p#

三.修復(fù)Bug:

Bug的原因是獲取的quotas并不屬于期望的用戶，但是直接修改context顯然不合適(會影響后續(xù)的操作)，先了解一下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方法的參數(shù)，默認(rèn)為None的project_id和user_id，這正是改變quotas屬主的方便入口!

修改后的代碼這里就不貼了，感興趣的同學(xué)可以到這次提交中看：Code Review

四.代碼提交和Review:

openstack社區(qū)有著整套項(xiàng)目管理流程，這里有一張圖能夠較詳細(xì)的描述工作流程：

由圖可見bugfix是其中最簡單的流程。

關(guān)于如何提交代碼，這篇文章有詳細(xì)的介紹： 向 OpenStack 貢獻(xiàn)您的代碼。另外需要注意一點(diǎn)，在國內(nèi)向社區(qū)提交代碼，經(jīng)常會因?yàn)榫W(wǎng)絡(luò)問題導(dǎo)致無法提交，幸好找到了大牛的博客介紹了該類問題的解決辦法。  修改完代碼的單元測試和pep8本地測試當(dāng)然不能少，早就知道社區(qū)對單元測試要求很嚴(yán)格，這次才真正領(lǐng)教了，三行代碼的修改，單元測試卻寫了30 行，review期間多次因?yàn)閱卧獪y試的問題重提代碼(哭)。社區(qū)里面的開發(fā)者，尤其是項(xiàng)目的core，對待項(xiàng)目有著像對自己孩子般的認(rèn)真與細(xì)致：他們會在一個自己根本不會在意的地方提醒你、面對當(dāng)前的問題他們會延伸的考慮類似的問題。他們的態(tài)度讓我首先感受到的吃驚，然后是敬佩!

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

感謝休倫公司技術(shù)總監(jiān) 孫琦 提供的英文支持，社區(qū)大牛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

關(guān)于OpenStack

OpenStack是一個由NASA(美國國家航空航天局)和Rackspace合作研發(fā)并發(fā)起的，是一個開源的云計(jì)算管理平臺項(xiàng)目，由幾個主要的組件組合起來完成具體工作。OpenStack支持幾乎所有類型的云環(huán)境，項(xiàng)目目標(biāo)是提供實(shí)施簡單、可大規(guī)模擴(kuò)展、豐富、標(biāo)準(zhǔn)統(tǒng)一的云計(jì)算管理平臺。

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