摘要：本文羅列了OpenStack Nova Ussuri版本的新增功能，並會對其中重要項進行詳細分析。
新增功能列表
重大變化
1. 支持在Nova cells間進行cold migrate和resize操作
相關概念
nova cell V2：
爲了降低數據庫和消息隊列的訪問瓶頸引入了cell的概念。
- 其中API Cell運行nova-api、nova-scheduler、nova-conductor服務，幷包含nova_api(全局數據)和nova_cell0(調度失敗的虛機數據)數據庫；
- 其餘每個Cell運行nova-compute、nova-conductor服務，幷包含獨立的消息隊列和nova(本cell詳細虛機數據，表項與nova_cell0相同)數據庫。
下圖是nova cell V2架構簡圖：
cold migrate & resize：
- 遷移是指將虛擬機從一個計算節點遷移到另外一個節點上(冷遷移過程中虛擬機時關機或者是處於不可用的狀態)；
- Resize則是根據需求重新調整虛擬機的計算能力和資源。
Resize和冷遷移的工作流程相同，區別只是Resize時必須保持新的Flavor配置大於舊的配置，而冷遷移則要求兩者相同。
需求由來
首先看下之前版本的cold migrate和resize流程，下圖基於Train版nova代碼：
,--------. ,--------------. ,--------------. ,---------. ,----------------. ,----------------.
|nova_api| |nova_conductor| |nova_scheduler| |placement| |nova_compute_dst| |nova_compute_src|
`---+----' `------+-------' `------+-------' `----+----' `-------+--------' `-------+--------'
Migrate VM| | | | | |
----------> | | | | |
| | | | | |
| RPC cast: | | | | |
| resize_instance() | | | | |
| ---------------------> | | | |
| | | | | |
| | MigrationTask | ,--------------------!. | |
| | ------------------------> |RPC call: |_\ | |
| | | |select_destination() | | |
| | | `----------------------' | |
| | | | | |
| | <- - - - - - - - - - - - | | |
| | | | | |
| | | RPC cast: | | |
| | | prep_resize() | | |
| | ----------------------------------------------------------------------------> |
| | | | | |
| | | |Restful: | |
| | | |GET /allocations/{consumer}| |
| | | |<--------------------------- |
| | | | | |
| | | |Restful: | ,------------------------------------!.
| | | |PUT /allocations/{consumer}| |Set inventory for placement provider|_\
| | | |<--------------------------- `--------------------------------------'
| | | | | |
| | | | | RPC cast: |
| | | | | resize_instance |
| | | | | -------------------------->
| | | | | |
| | | | | RPC cast: |
| | | | | finish_resize() |
| | | | | <--------------------------
| | | | | |
confirm | | | | | |
----------> | | | | |
| | | | | |
| | | RPC cast: | | |
| | | confirm_resize()| | |
| ------------------------------------------------------------------------------------------------------------------------------->
| | | | | |
revert | | | | | |
----------> | | | | |
| | | | | |
| | RPC cast: | | |
| | revert_resize() | | |
| ---------------------------------------------------------------------------------------------------> |
| | | | | |
| | | | | RPC cast: |
| | | | | finish_revert_resize() |
| | | | | -------------------------->
,---+----. ,------+-------. ,------+-------. ,----+----. ,-------+--------. ,-------+--------.
|nova_api| |nova_conductor| |nova_scheduler| |placement| |nova_compute_dst| |nova_compute_src|
`--------' `--------------' `--------------' `---------' `----------------' `----------------'
主要分爲5個階段：
1、nova-conductor/nova-scheduler選擇計算節點
nova-conductor通過select_destination訪問nova-scheduler進行調度，選擇一個合適的目的節點（resize操作與源節點相同）。
2、pre_resize階段，預備遷移
會在目的主機進行相同節點是否支持遷移檢查以及其他檢查，並會向placement查詢新節點是否滿足分配，並佔用Inventory。然後通知源節點執行resize_instance。
3、resize_instance階段
這一階段會關閉源節點網絡、磁盤等設備，並通過scp(rsync可選)向遠端節點拷貝磁盤數據，同節點執行cp指令。然後通知目標節點，resize結束。
4、結束遷移
目標節點收到finish_resize，開始配置網絡、掛在卷並啓動虛機。
5、確認遷移
這裏給予用戶一次反悔撤銷的機會，若確認將會刪除源節點虛機數據否則進行遷移回退。
U版本邏輯
上圖中nova_compute_src(源計算節點)和nova_compute_dst(目標計算節點)間直接通過消息隊列進行通信，而由於新引入了cell V2架構，放到跨cell場景時，雙方無法通過消息隊列進行通信，自然會失敗，故只能在同cell內進行resize和cold migrate操作。U版本爲了解決這一問題，在跨cell進行冷遷移或者resize時，會統一由API Cell的nova-conductor來指揮整個過程，不讓src compute和dest compute節點通訊，且與nova-conductor都通過RPC call進行通信（當然，同cell內的虛擬機遷移仍然保持之前的邏輯）。新增邏輯的順序圖如下：
,--------. ,--------------. ,--------------. ,---------. ,----------------. ,----------------.
|nova_api| |nova_conductor| |nova_scheduler| |placement| |nova_compute_dst| |nova_compute_src|
`---+----' `------+-------' `------+-------' `----+----' `-------+--------' `-------+--------'
Migrate VM| | | | | |
----------> | | | | |
| | | | | |
| RPC cast: | | | | |
| migrate_server() | | | | |
| -------------------------------> | | | |
| | | | | |
| | MigrationTask | ,--------------------!. | |
| | ---------------------------------------------> |RPC call: |_\ | |
| | | |select_destination() | | |
| | | `----------------------' | |
| | | | | |
| | <- - - - - - - - - - - - - - - - - - - - - - - | | |
| | | | | |
| | | | | |
| | | ========================== | |
=================================================================================================== CrossCellMigrationTask ===================================================================================================
| | | ========================== | |
| | | | | |
| | PrepResizeAtDestTask | | ,------------------------------------!.
| | -------------------------------------------------------------------------------------------------> |RPC call: |_\
| | | | | |prep_snapshot_based_resize_at_dest() |
| | | | | `--------------------------------------'
| | | | | |
| | <- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - |
| | | | | |
| | | |Restful: | |
| | | |GET /allocations/{consumer}| |
| | | |<--------------------------- |
| | | | | |
| | | |Restful: | ,------------------------------------!.
| | | |PUT /allocations/{consumer}| |Set inventory for placement provider|_\
| | | |<--------------------------- `--------------------------------------'
| | | | | |
| | | PrepResizeAtSourceTask | | ,--------------------------------------!.
| | -----------------------------------------------------------------------------------------------------------------------------> |RPC call: |_\
| | | | | | |prep_snapshot_based_resize_at_source() |
| | | | | | `----------------------------------------'
| | | | | |
| | <- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
| | | | | |
| | FinishResizeAtDestTask | | ,--------------------------------------!.
| | -------------------------------------------------------------------------------------------------> |RPC call: |_\
| | | | | |finish_snapshot_based_resize_at_dest() |
| | | | | `----------------------------------------'
| | | | | |
| | <- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - |
| | | | | |
| |----. ,-------------------------!. | | |
| | | FinishResizeAtDestTask |update_instance_mapping()|_\ | | |
| |<---' `---------------------------' | | |
| | | | | |
confirm | | | | | |
----------> | | | | |
| | | | | |
| RPC cast: | | | | |
| confirm_snapshot_based_resize()| | | | |
| -------------------------------> | | | |
| | | | | |
| | | | | |
| | | ===================== | |
===================================================================================================== ConfirmResizeTask ======================================================================================================
| | | ===================== | |
| | | | | |
| | RPC call: | | |
| | confirm_snapshot_based_resize_at_source() | |
| | ----------------------------------------------------------------------------------------------------------------------------->
| | | | | |
| | | | | |
| | <- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
| | | | | |
| |----. | | | |
| | | hard delete source cell instance | | | |
| |<---' | | | |
| | | | | |
| |----. | | | |
| | | update target cell instance status | | | |
| |<---' | | | |
| | | | | |
revert | | | | | |
----------> | | | | |
| | | | | |
| | RPC cast: | | | |
| | revert_snapshot_based_resize() | | |
| ----------------------------------------------------------------------------------------------------------------------------------> |
| | | | | |
| | | | | |
| | | =================== | |
====================================================================================================== ReverResizeTask =======================================================================================================
| | | =================== | |
| | | | | |
| |----. | | |
| | | update records from target to source cell | | |
| |<---' | | |
| | | | | |
| |----. | | | |
| | | update instance mapping | | | |
| |<---' | | | |
| | | | | |
| | RPC call: | | | |
| | revert_snapshot_based_resize_at_dest() | | |
| | -------------------------------------------------------------------------------------------------> |
| | | | | |
| | | | | |
| | <------------------------------------------------------------------------------------------------- |
| | | | | |
| |----. | | | |
| | | hard delete target cell instance | | | |
| |<---' | | | |
| | | | | |
| | RPC call: | | |
| | finish_revert_snapshot_based_resize_at_source() | |
| | ----------------------------------------------------------------------------------------------------------------------------->
| | | | | |
| | | | | |
| | <- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
,---+----. ,------+-------. ,------+-------. ,----+----. ,-------+--------. ,-------+--------.
|nova_api| |nova_conductor| |nova_scheduler| |placement| |nova_compute_dst| |nova_compute_src|
`--------' `--------------' `--------------' `---------' `----------------' `----------------'
U版本resize流程主要分爲5個Task：
1、MigrationTask
nova-conductor會先判斷目標節點與源節點是否在同一個cell，若在相同cell，則執行U版本之前的邏輯，會涉及源、目的節點的通信；若不在同一個cell，則將執行CrossCellMigrationTask。
2、PrepResizeAtDestTask
聲明資源並對目標節點中的選定主機進行驗證，與之前版本的pre_resize階段功能類似。
3、PrepResizeAtSourceTask
在源主機上準備實例(停止虛機，可以選擇對其進行快照，斷開卷和關閉網絡等操作)，與之前版本的resize_instance階段類似，不過此時發起方爲nova-conductor。這裏提到了快照，由於跨cell，無法將根磁盤直接拷貝到目標主機，這裏採用對根磁盤打快照並上傳到Glance中的方式來達到數據遷移的目的(對於卷啓動的虛機則直接通過向目標節點掛載根卷的方式來完成數據遷移)。
4、FinishResizeAtDestTask
在目標主機上完成調整大小(遷移)，交換實例上的隱藏字段並更新實例映射，與之前版本的結束遷移階段類似，不過此時的發起方爲nova-conductor。
5、確認遷移
這裏給予用戶一次反悔撤銷的機會，若確認將會刪除源節點虛機數據，否則進行遷移回退。同樣，跨cell時發起方revert操作的發起方也變爲nova-conductor。
2. 支持nova-manage placement auditCLI，以查找和清理孤立的資源分配
placement孤立資源會導致
-
實際可分配資源使用量較少
-
無法刪除作爲resource provider的計算節點
產生原因
可能發生這種情況的一種情況是當計算節點出現問題，因此管理員將其強制關閉並從中撤離虛機。請注意，在這種情況下，“撤離”是指虛擬機evacuate操作，而不是從正在運行的計算服務實時遷移所有服務器。假定計算節點已關閉並且被隔離。假設vm1已經從計算節點devstack1撤離到計算節點devstack2：
$ openstack --os-compute-api-version 2.53 compute service list --service nova-compute
+--------------------------------------+--------------+-----------+------+---------+-------+----------------------------+
| ID | Binary | Host | Zone | Status | State | Updated At |
+--------------------------------------+--------------+-----------+------+---------+-------+----------------------------+
| e3c18c2d-9488-4863-b728-f3f292ec5da8 | nova-compute | devstack1 | nova | enabled | down | 2019-10-25T20:13:51.000000 |
| 50a20add-cc49-46bd-af96-9bb4e9247398 | nova-compute | devstack2 | nova | enabled | up | 2019-10-25T20:13:52.000000 |
| b92afb2e-cd00-4074-803e-fff9aa379c2f | nova-compute | devstack3 | nova | enabled | up | 2019-10-25T20:13:53.000000 |
+--------------------------------------+--------------+-----------+------+---------+-------+----------------------------+
$ vm1=$(openstack server show vm1 -f value -c id)
$ openstack server show $vm1 -f value -c OS-EXT-SRV-ATTR:host
devstack2
此時，placement中的devstack1和devstack2資源提供者已經進行了分配：
$ devstack1=$(openstack resource provider list --name devstack1 -f value -c uuid)
$ devstack2=$(openstack resource provider list --name devstack2 -f value -c uuid)
$ openstack resource provider show --allocations $devstack1
+-------------+-----------------------------------------------------------------------------------------------------------+
| Field | Value |
+-------------+-----------------------------------------------------------------------------------------------------------+
| uuid | 9546fce4-9fb5-4b35-b277-72ff125ad787 |
| name | devstack1 |
| generation | 6 |
| allocations | {u'a1e6e0b2-9028-4166-b79b-c177ff70fbb7': {u'resources': {u'VCPU': 1, u'MEMORY_MB': 512, u'DISK_GB': 1}}} |
+-------------+-----------------------------------------------------------------------------------------------------------+
$ openstack resource provider show --allocations $devstack2
+-------------+-----------------------------------------------------------------------------------------------------------+
| Field | Value |
+-------------+-----------------------------------------------------------------------------------------------------------+
| uuid | 52d0182d-d466-4210-8f0d-29466bb54feb |
| name | devstack2 |
| generation | 3 |
| allocations | {u'a1e6e0b2-9028-4166-b79b-c177ff70fbb7': {u'resources': {u'VCPU': 1, u'MEMORY_MB': 512, u'DISK_GB': 1}}} |
+-------------+-----------------------------------------------------------------------------------------------------------+
$ openstack --os-placement-api-version 1.12 resource provider allocation show $vm1
+--------------------------------------+------------+------------------------------------------------+----------------------------------+----------------------------------+
| resource_provider | generation | resources | project_id | user_id |
+--------------------------------------+------------+------------------------------------------------+----------------------------------+----------------------------------+
| 9546fce4-9fb5-4b35-b277-72ff125ad787 | 6 | {u'VCPU': 1, u'MEMORY_MB': 512, u'DISK_GB': 1} | 2f3bffc5db2b47deb40808a4ed2d7c7a | 2206168427c54d92ae2b2572bb0da9af |
| 52d0182d-d466-4210-8f0d-29466bb54feb | 3 | {u'VCPU': 1, u'MEMORY_MB': 512, u'DISK_GB': 1} | 2f3bffc5db2b47deb40808a4ed2d7c7a | 2206168427c54d92ae2b2572bb0da9af |
+--------------------------------------+------------+------------------------------------------------+----------------------------------+----------------------------------+
可以通過下面方式查看撤離記錄：
$ nova migration-list --source-compute devstack1 --migration-type evacuation
+----+--------------------------------------+-------------+-----------+----------------+--------------+-------------+--------+--------------------------------------+------------+------------+----------------------------+----------------------------+------------+
| Id | UUID | Source Node | Dest Node | Source Compute | Dest Compute | Dest Host | Status | Instance UUID | Old Flavor | New Flavor | Created At | Updated At | Type |
+----+--------------------------------------+-------------+-----------+----------------+--------------+-------------+--------+--------------------------------------+------------+------------+----------------------------+----------------------------+------------+
| 1 | 8a823ba3-e2e9-4f17-bac5-88ceea496b99 | devstack1 | devstack2 | devstack1 | devstack2 | 192.168.0.1 | done | a1e6e0b2-9028-4166-b79b-c177ff70fbb7 | None | None | 2019-10-25T17:46:35.000000 | 2019-10-25T17:46:37.000000 | evacuation |
+----+--------------------------------------+-------------+-----------+----------------+--------------+-------------+--------+--------------------------------------+------------+------------+----------------------------+----------------------------+------------+
此時嘗試刪除devstack1的resource provider將失敗：
$ openstack resource provider delete $devstack1
Unable to delete resource provider 9546fce4-9fb5-4b35-b277-72ff125ad787: Resource provider has allocations. (HTTP 409)
新增查找孤立資源的意義
對於上述例子，是既定條件下的問題復現，但是在實際的生產環境中往往會出現許多無法快速定位的孤立資源，對於運維管理人員的排查處理會造成很大影響。而新增的孤立資源查找方法將解決這一問題：
nova-manage placement audit [--verbose] [--delete] [--resource_provider <uuid>]
執行該命令後會遍歷所有的resource provider(如果提供resource provider的UUID，則只遍歷其本身)，然後驗證、計算是否存在與現有實例或遷移UUID相關的分配。如果不相關，將會輸出哪些分配是孤立的。
-
可以通過指定-delete來要求刪除所有孤立的分配(osc-placement1.7.x以前版本需要手動覆蓋分配後再刪除；1.8版本之後則需要使用unset命令後再刪除)；
-
通過指定--verbose以獲取執行期間的詳細進度輸出；
-
此命令要求設置api_database.connection和Placement配置選項。必須輸入Placement API> = 1.14。
返回代碼：
3. 支持具有resource request的neutron port的實例的撤離，實時遷移和擱置
相關概念
Port Resource Requests：
在Neutron Port屬性中包含resource request(用於向placement查詢、更新)，比如QOS Minimal bandwidth rule。Nova在創建或移動實例時，會從每個port收集並組合resource request，在調度期間將一個allocation請求發送到placement，placement將確保目標provider能夠滿足該port的資源請求。
Port resource requests樣例如下：
{u'required': [u'CUSTOM_PHYSNET_PHYSNET1',
u'CUSTOM_VNIC_TYPE_NORMAL'],
u'resources': {u'NET_BW_EGR_KILOBIT_PER_SEC': 1000,
u'NET_BW_IGR_KILOBIT_PER_SEC': 1000}}
-
CUSTOM_PHYSNET_PHYSNET1對應物理網絡名稱，由neutron ovs-agent/sr-iov-agent配置項bridge_mappings來定義；
-
CUSTOM_VNIC_TYPE_NORMAL爲該port類型；
-
NET_BW_EGR_KILOBIT_PER_SEC和NET_BW_IGR_KILOBIT_PER_SEC表明最小帶寬出入方向的限制大小。
歷史情況
從Microversion 2.72開始，nova支持使用neutron port創建服務器時，port具有可見的資源請求（僅管理員端口屬性） resource_request。例如，如果neutron port附加了QoS最小帶寬規則，則它具有resource request。自從Stein版本的nova以來，刪除此類實例或分離此類port是可行的，而無需任何特定的microversion。
但是，nova仍不支持以下API操作：
-
不支持使用具有QoS最小帶寬規則的neutron network創建實例。用戶需要在該network中預先創建port，使用該port創建實例。
-
不支持連接具有QoS最小帶寬規則的Neutron port和network。
另外，nova的19.0.0（Stein）版本不支持以下API操作：
-
尚不支持使用具有resource request的port來移動（resizing, migrating, live-migrating, evacuating, unshelving after shelve offload）實例。
從20.0.0（Train）開始，nova支持具有資源請求的中子端口的服務器的冷遷移和調整大小，需要滿足以下兩個方面的要求：
-
源和目標計算服務都升級到20.0.0（Train）；
-
[upgrade_levels]/compute配置不阻止使用最新的RPC版本；
原理概述
這裏以創建帶有resource_request端口的實例爲例，其餘實現思路類似，大體爲：
,--------. ,--------------. ,--------------. ,---------. ,------------.
|nova_api| |nova_conductor| |nova_scheduler| |placement| |nova_compute|
`---+----' `------+-------' `------+-------' `----+----' `-----+------'
| | | | |
| | ======================================= | |
========================================================================= Image cache management by aggregate ==========================================================================
| | ======================================= | |
| | | | |
boot | | | | |
---------------------------> | | | |
| | | | |
,----------------------!. |----. | | |
|Get resource request |_\| | _validate_and_build_base_options() | | |
|and generate req_specs ||<---' | | |
`------------------------'| | | | |
| RPC cast: | | | |
| schedule_and_build_instances() | | | |
| --------------------------------------> | | |
| | | | |
| | RPC call: | | |
| | select_destinations() | | |
| | ------------------------> | |
| | | | |
| | | | |
| | <- - - - - - - - - - - - | |
| | | | |
| | | Restful: | |
| | | GET /allocation_candidates?{resources}| |
| | | --------------------------------------> |
| | | | |
| | | | |
| | | <- - - - - - - - - - - - - - - - - - - |
| | | | |
| | | RPC cast: | ,-.
| | | build_and_run_instance() | |X|
| | --------------------------------------------------------------------------------------------->|X|
| | | | |X|
| | | | Restful: |X|
| | | | GET /allocations/{consumer} |X|
| | | | <---------------------------|X|
| | | | |X|
| | | | Restful: |X| ,-------!.
| | | | PUT /allocations/{consumer} |X| |Spawing|_\
| | | | <---------------------------|X| `---------'
| | | | `-'
| | | RPC cast: | |
| | | update_instance_info() |
| | | <--------------------------------------------------------------------
,---+----. ,------+-------. ,------+-------. ,----+----. ,-----+------.
|nova_api| |nova_conductor| |nova_scheduler| |placement| |nova_compute|
-
獲取port_resource_request並構建req_specs；
-
根據req_specs向placement查詢相關的分配信息，這裏是qos limit，過濾出目標計算節點；
-
在目標節點創建實例並向placement佔用該部分資源；
4. Nova Policies引入具有scope_type的新默認角色
在Ussuri（21.0.0）版本中引入了具有scope_type功能的新默認角色，這些新更改提高了安全級別和可管理性。在處理具有“讀取”和“寫入”角色的系統和項目級別令牌的訪問權限方面，新策略更加豐富，處理了以下問題：
-
沒有全局項目管理員。該admin_only角色用於全局管理員，該管理員幾乎可以對Nova進行任何更改，並查看Nova系統的所有詳細信息。該規則適用於具有管理員角色的任何用戶，使用哪個項目都沒有關係。
-
沒有隻讀角色。由於多個API傾向於共享用於讀取和寫入操作的單個策略規則，因此它們沒有提供只讀訪問角色所需的粒度。
-
角色admin_or_owner沒有按照預期工作。大多數具有admin_or_owner角色的API，項目身份驗證發生在與Nova中的API不同的組件中，該組件不遵守策略更改。結果導致policy無法覆蓋項目內硬編碼的策略。
keystone自帶admin、member、reader默認角色。此外，keystone支持新的“system scope”概念，可以更輕鬆地保護部署級資源免受項目或系統級資源的侵害。
在Nova 21.0.0（Ussuri）版本中，Nova Policy實現了scope概念且默認角色使用了keystone提供的admin、member、reader。使用Keystone中的常見角色可以減少重複定義角色的可能性，但是，角色往往由項目或部署實施時來定義。而藉助新的默認設置，可以更輕鬆地瞭解誰可以跨項目執行操作，減少分歧並提高互操作性。
以下各節說明了Nova中的這些新默認值如何解決上述前兩個問題，並以安全可靠的方式將更多功能擴展到最終用戶。
Scope
OpenStack Keystone支持在token中的使用不同scope。token作用域代表授權層。策略scope_types表示訪問API所需的授權層。
每個策略的scope_type是硬編碼的，並且不能通過policy文件覆蓋
Nova通過在policy文件中定義scope_type來實現範圍的概念。要了解nova每個策略的scope_type，
請參考：https://docs.openstack.org/nova/latest/configuration/policy.html
下面給出各個scopy_type的示例：
system scope
scope_type爲system的policies意味着具有system-scoped token的用戶纔有權限訪問該資源。它可以理解爲全局角色。默認情況下，所有系統級別操作policies的scope_type都爲[system]。
例如：GET /os-hypervisors API
# List all hypervisors.
# GET /os-hypervisors
# Intended scope(s): system
#"os_compute_api:os-hypervisors:list": "rule:system_reader_api"
system and project scope
具有system_type和system-project的策略的策略意味着具有系統範圍或項目範圍的令牌的用戶纔有權限訪問該資源。默認情況下，所有系統和項目級操作的policies的scope_type都爲['system'，'project']。
例如：POST /servers/{server_id}/action（os-migrateLive）API
# Live migrate a server to a new host without a reboot
# POST /servers/{server_id}/action (os-migrateLive)
# Intended scope(s): system, project
#"os_compute_api:os-migrate-server:migrate_live": "rule:system_admin_api"
這些作用域類型提供了一種區分系統級和項目級訪問角色的方法。您可以根據用戶範圍控制信息。這意味着可以控制任何項目級別角色都無法獲取虛擬機監控程序信息。默認情況下，policy scope是禁用的，主要方便運維實施人員將舊的policy進行遷移。可以通過將oslo_policy.enforce_scope配置想設置爲True來啓用此功能。
Roles
您可以參考該文檔以瞭解Keystone中所有可用的默認設置。
與scope_type功能一起，Nova策略爲每個策略定義了新的默認值。
Reader
這提供對系統或項目內資源的只讀訪問。Nova默認規則：
system_reader_api
Default
role:reader and system_scope:all
system_or_project_reader
Default
(rule:system_reader_api) or (role:reader and project_id:%(project_id)s)
Member
該角色是結合系統管理員執行項目級別的寫操作。Nova默認規則：
project_member_api
Default
role:member and project_id:%(project_id)s
system_admin_or_owner
Default
(role:admin and system_scope:all) or (role:member and project_id:%(project_id)s)
Admin
該角色是在系統以及項目級別的操作上執行管理員級別的寫操作。Nova默認規則：
system_admin_api
Default
role:admin and system_scope:all
project_admin_api
Default
role:admin and project_id:%(project_id)s
system_admin_or_owner
Default
(role:admin and system_scope:all) or (role:member and project_id:%(project_id)s)
使用這些新的默認值，可以解決以下問題：
-
向用戶提供只讀訪問權限。制定了更加精細的策略，並默認使用reader role。例如：比如出於安全目的需要讓他人審覈部署的系統。
-
以更好的方式自定義策略。例如，能夠向項目級別的用戶提供訪問權限，以對其服務器或帶有其令牌的任何其他項目執行實時遷移。
遷移計劃
請參考該鏈接：https://docs.openstack.org/nova/latest/configuration/policy-concepts.html#migration-plan
5. 從卷啓動的虛擬機能夠使用Rescue操作，允許將穩定的磁盤設備連接到救援實例
相關概念
rescue：
openstack 救援模式是把鏡像作爲實例的系統盤，把實例的原系統盤作爲數據盤，這樣可以將數據盤mount到文件系統，對原系統文件進行修改以達到拯救目的。
此前版本boot from volume的實例不支持rescue操作的原因
首先其實早在2012年，就有人提交過一個與U版當前實現相似的patch來解決這個問題(可能不太professional，感興趣可以對比一下當前代碼：https://launchpadlibrarian.net/119948767/nova_libvirt_rescue_bdm.patch)，實現方式是向後端驅動(libvirt)傳遞block_device_mapping，通過bdm獲取boot from volume實例的根磁盤信息。而當時否決這一做法的理由是：
rescue操作提供了一種訪問無法啓動實例的手段，而從卷啓動的實例的根磁盤可以直接掛載，通過rescue是沒有意義的，所以禁止BFV實例執行rescue
並且提交了一個commit從api層禁止了這樣的操作。個人覺得該理由比較牽強且固執，並且對新的有意加入社區的開發人員極不友好。好在終於在U版，這一功能合併了進來，使得rescue操作更加地專業統一。
6. 根據aggregate預緩存image到計算節點
相關概念
Host Aggregates：
Host Aggregates是一種基於任意特徵在region中對主機進行劃分的機制。可以根據不同的 computes 節點的物理硬件配置將具有相同共性的物理資源規劃在同一 Host Aggregates 之下，或者根據用戶的具體需求將幾個 computes 節點規劃在具有相同用途的同一 Host Aggregate 之下，通過這樣的劃分有利於提高 OpenStack 資源的使用效率。
API介紹：
POST /os-aggregates/{aggregate_id}/images
請求將一組圖像預先緩存在引用的聚合內的計算節點上
從microversion 2.81開始提供此API。響應代碼：
-
正常響應碼：202
-
錯誤響應代碼：badRequest（400），unauthorized（401），forbidden（403），itemNotFound（404）
Request
request示例：
{
"cache":
[
{"id": "70a599e0-31e7-49b7-b260-868f441e862b"}
]
}
原理概述
,--------. ,--------------. ,------------.
|nova_api| |nova_conductor| |nova_compute|
`---+----' `------+-------' `-----+------'
| | |
| =======================================
================================== Image cache management by aggregate ==================================
| =======================================
| | |
Prefetch img in | | |
aggregate host | | |
----------------> | |
| | |
|----. | |
| | get_aggregate() | |
|<---' | |
| | |
| RPC cast: | |
| cache_images() | |
| ---------------------> |
| | |
| | | ,---------------------------!.
| | cache_images() | |RPC call: |_\
| | -----------------------> |Create a green-thread pool |
| | | |to cache images for each |
| | | |comput node under each cell |
,---+----. ,------+-------. ,-----+--`-----------------------------'
|nova_api| |nova_conductor| |nova_compute|
`--------' `--------------' `------------'
-
nova-api根據Restful請求獲取aggregate列表；
-
nova-conductor根據aggregate找到所有的相關計算節點，並獲取cell_mapping，以便獲取各個cell的context；
-
以本cell的context向cell內的計算節點發送cache_images的請求；
-
再有計算節點驅動調用glance client去下載鏡像。
7. 計算節點支持多種虛擬GPU類型
此次還對虛擬GPU類型的支持做了優化，此前，指定實例使用何種類型的虛擬GPU需要修改如下配置文件：
[devices]
enabled_vgpu_types = nvidia-35
如果要支持多個GPU類型，則需要爲每個設備提供單獨的配置部分。例如：
[devices]
enabled_vgpu_types = nvidia-35, nvidia-36
[vgpu_nvidia-35]
device_addresses = 0000:84:00.0,0000:85:00.0
[vgpu_nvidia-36]
device_addresses = 0000:86:00.0
必須在其中定義每種GPU類型支持哪些物理GPU。如果爲兩種不同類型提供了相同的PCI地址，nova-compute將拒絕啓動並在日誌中發出特定錯誤。
8. 支持在創建虛擬機時通過Cyborg來附加加速設備