盤點Openstack那些頑固bug
本文將盤點Openstack中那些頑固bug，這些bug至少存活了一年。
1. 設置quota時沒有檢查租戶是否存在
- bug地址:Nova should confirm quota requests against Keystone。
- report時間: 2013-02-07
- 存活壽命: 3歲半
當設置quota時需要指定租戶project/tenant，但是目前nova和cinder都不會對租戶是否存在進行檢查，當該租戶的quota記錄不存在時就創建一個新的quota記錄。比如：
- cinder quota-update --volumes 10 any-string
以上無論你輸入任何字符串，都會返回200 OK，即使租戶并不存在。
由于租戶配額管理只有admin角色有權限，因此必須假定:
And as an admin (trusted user), we expect them to not break things.
即管理員是可信任的，假定你不會把事情搞砸。
當然作為管理員惡意攻擊不太可能，不過很多管理員都可能會把租戶輸成租戶名，而注意該API只支持租戶id,你輸入租戶名不會報錯，但不會生效。
該bug難以解決的原因是目前keystone尚無實現檢查租戶是否存在的接口。
針對該bug已經提交成一個獨立的BP，validate-project-with-keystone,并將在下個版本Ocata實現。
使用python-openstackclient會對租戶進行檢查，設置quota時可以考慮使用該client取代。
2. 使用統一分布式存儲時計算磁盤空間錯誤
- bug地址: nova hypervisor-stats shows wrong disk usage with shared storage
- report時間: 2015-01-25
- 存活壽命: 1歲半
nova hypervisor-stats命令用于獲取整個Openstack集群可用的物理資源總量，統計包括cpu、內存和磁盤三種資源，實現方法是由各個計算節點的resource_tracker統計該節點的資源量，并定期更新到數據庫中。nova調用hypervisor-stats時即對所有計算節點的資源求總和。對于cpu以及內存完全沒有問題，但如果使用分布式共享存儲作為后端存儲時，計算磁盤空間就是錯誤的，因為每個計算節點看到的資源都是分布式存儲的總資源量大小。比如使用ceph做后端存儲，每個計算節點看到的都是ceph df看到可用空間的大小，在計算資源總和時不應該再相加，否則就相當于多算了N倍。因此如果有N個計算節點，相當于對資源計算多算了N倍。
3. 軟刪除存在DOS漏洞。
- bug地址: Enabling soft-deletes opens a DOS on compute hosts
- report時間: 2015-10-01
該bug是一個安全漏洞，不過已于今年1月公開。
Openstack支持虛擬機軟刪除功能，用戶可以設置虛擬機的保留時間。當用戶刪除虛擬機時，不會真的立即刪除虛擬機，而僅僅是做一個刪除標記，保留時長為設置的保留時間，當超過保留時間時，系統才真正清理虛擬機。該功能能夠使用戶不慎刪除虛擬機能立即撤回操作，避免數據丟失。
換句話說，虛擬機軟刪除時，虛擬機的資源并沒有釋放，并且不占用戶配額。惡意用戶可以不斷創建虛擬機不斷刪除虛擬機，直到耗盡所有的物理資源。
Michael Still說:
This is definitely be design. That said I agree there is a DoS possible here.
It seems to me there is a tweak we could make where if a hypervisor becomes space constrained we delete earlier than the configured time, but that might be a surprise for administrators using a “fill first” scheduling methodology.
因此這個bug至今尚未修復。
4.console.log文件可能占據整個磁盤空間
- bug地址: console.log grows indefinitely
- report時間: 2011-08-24
- 存活壽命: 5歲
console log保存虛擬機啟動時的日志，用戶可以使用nova console-log命令查看，KVM會把所有的標準輸出打印到console.log中，并且沒有大小限制，如果用戶無休止地發送數據到stdout中，console.log文件將可能占據整個磁盤空間。
該bug在不斷修復過程中，至今沒有徹底修復。
5. Nova和cinder數據卷掛載狀態不一致
bug地址: Nova and Cinder get desynced on volume attachments report時間： 2015-09-23
該bug很早就已經存在，只是到2015年才有人report。 通常卸載volume卷包括如下三個步驟:
- 1 調用libvirt卸載磁盤設備
- 2 通知cinder
- 3 刪除BDM(block device mapping)記錄
如果第一步失敗，此時虛擬機處于error狀態，但volume掛載狀況和cinder仍然是同步的，只需要執行reset-state回滾即可。
如果第二步失敗，此時nova認為volume已經卸載了，但cinder沒有接收到通知，仍然認為volume是被掛載的。此時nova不能再執行detach操作，因為volume已經不存在了。但cinder也不能再執行掛載操作，因為volume還處于in-use狀態。修復辦法是使用cinder reset-stat或者只能修改數據庫了。
【本文是51CTO專欄作者“付廣平”的原創文章，如需轉載請通過51CTO獲得聯系】
