OpenStack Ussuri 版新特性: Nova功能分析
摘要：本文罗列了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 ] 执行该命令后会遍历所有的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来附加加速设备