最近遇到一個bug，是使用者在nova端attach一個volume給instance後，再發起detach操作，導致該volume detach失敗且一直處於detaching狀態，藉此走讀nova volume-detach的程式碼流程，在此分享下心得筆記。

nova client端發起nova volume-attach動作，首先在api側獲取到請求資訊，並進行簡單解析：

nova/api/openstack/compute/volume.py

def _attach_volume(self, context, instance,             volume_id, device, disk_bus, device_type)
 
:
    """Attach an existing volume to an existing instance.This method is separated to make it possible for cells version to override it.
    """

根據請求來的body，獲取volume及instance資訊，直接呼叫compute api：

    device = self.compute_api.attach_volume(context, instance,volume_id, device)

compute api收到請求進行處理，
nova/compute/api.py：

def attach_volume(self, context, instance, volume_id, device=Nonedisk_bus=None, device_type=None):

這裡比較簡單，直接返回另一方法：

return self._attach_volume(context, instance, volume_id, device, disk_bus, device_type)

再看_attach_volume方法：

def _attach_volume(self, context, instance, volume_id, device, disk_bus, device_type)
 
:

這部分主要建立bdm，rpc呼叫nova compute：

self.compute_rpcapi.attach_volume(context, instance, volume_bdm)

openstack下的rpc呼叫，最終都是由manager.py處理，所以直接看compute下的manager.py
nova/compute/manager.py：

def attach_volume(self, context, instance, bdm):
return self._attach_volume(context, instance, driver_bdm)

def _attach_volume(self, context, instance, bdm):
bdm.attach(context, instance, self.volume_api, self.driver,
           do_driver_attach=True)

直接看第二個方法，發起呼叫bdm.attach，在nova/virt/block_device.py中：

def attach(self, context, instance, volume_api, virt_driver, do_driver_attach=False, **kwargs):

在這裡有以下幾部分操作：
1）獲取connect_info
2）呼叫driver將volume掛載給instance的動作（修改xml配置等）；

virt_driver.attach_volume

3）檢查connect_info資訊
4）如果volume狀態是detached：

if volume['attach_status'] == "detached":

則呼叫cinder中attach方法，會將volume設定為in-use狀態：

volume_api.attach(context, volume_id, instance.uuid,
                  self['mount_device'], mode=mode)

在呼叫cinder之前，有一個connect_info儲存動作：

self.save()

正常在attach方法有裝飾器修飾：

@update_db

在attach執行後更新資料庫，儲存connect_info資訊。
在呼叫cinder之前加上儲存的動作是為了防止在attach之後又
發生detach動作，此時cinder返回volume為in-use狀態，但是connect_info尚未儲存到資料庫，在detach流程
中可能會因為獲取不到有效的connect_info資訊而導致detach失敗：

TRACE oslo.messaging.rpc.dispatcher TypeError: <type 'NoneType'> can't be decoded

使得volume一直處於detaching狀態。

小笨驢在吃草的時候建立了微信公眾號，為方便更多覓食的“小笨驢”，為大家準備了大量的免費基礎教學資料以及技術解決方案，還會定時釋出一些好的技術文章，當然也會扯扯蛋、談談人生、呵呵，希望我們這群樂於分享技術的“小笨驢”團隊越來越大！（技術乾貨分享群qq：128015753）