OpenStack之Provisioning Blocks管理复杂对象的状态

我们使用对象的STATUS字段表示资源是否可用，如果设置为ACTIVE，外部系统认为可以安全的使用此资源。如果仅有一个实体负责配置（provisioning）给定的对象，很容易知道合适将status设置为ACTIVE。当实体完成配置（provisioning），我们就更新STATUS到ACTIVE。尽管如此，在Neutron内部由许多资源需要在可用之前由多个异步的实体进行配置（provisioning），所以管理status到ACTIVE状态的转变变得更加复杂。为处理此情况，Neutron增加了 模块用于跟踪正在配置（provisioning）资源的实体。

High Level View

要使用provisioning_blocks模块，即当对象的status转换为ACTIVE之前，需要另外的实体完成工作，必须添加配置（provisioning）组件。通过为每个实体调用方法add_provisioning_component来实现。当每个实体完成配置（provisioning）对象后，provisioning_complete被调用移除配置（provisioning）块。

当最后一个配置块被移除后，provisioning_blocks模块将触发回调通知，其中包含对象资源类型的对象ID，事件为PROVISIONING_COMPLETE。此事件的订阅者现在可更新对象的status到ACTIVE状态，或者执行其它需要的动作。

通常的状态转变过程如下:

关于更精确的示例，参见以下章节.

ML2, L2 agents, 和 DHCP agents

ML2使用provisioning_blocks模块防止在L2 agent和DHCP agent完成port连接工作之前，将port的status转换到ACTIVE状态。

当port创建或更新，以下步骤注册DHCP agent的配置（provisioning）块：

1. 从port的fixed_ips字段抽取出来 subnet_ids，之后ML2检查DHCP是否在其中的subnet上启用。
2. 查找承载网络的DHCP agent配置以确保至少有一个足够新的可报告其完成了port预留。
3. 以上的两个条件有一个失败的话，DHCP agent的配置（provisioning）块将不会添加，并且任何现存的阻塞此port的DHCP agent将被清除，以保证port不会阻塞在等待一个不会发生的事件。
4. 如果以上的条件成立，port的配置（provisioning）块被添加在“DHCP”实体下。

当port创建或更新，以下步骤注册L2 agent的配置（provisioning）块:

1. 如果port没有绑定，不做任何事，因为我们还不知道是否会涉及到L2 agent，所以必须等待绑定端口的更新.
2. 一旦port绑定，基于agent的mechanism驱动将检查绑定主机上是否存在agent，VNIC类型是否属于mechanism驱动，port的配置（provisioning）块被添加在“L2 agent”实体下.

一旦DHCP agent完成预留的建立，它通过带有port ID的RPC API调用dhcp_ready_on_ports。DHCP RPC处理器接收到，调用配置（provisioning）模块中的“provisioning_complete”，带有port ID，并且“DHCP”实体去删除配置（provisioning）块。

一旦L2 agent完成预留的建立，它通过RPC API调用正常的update_device_list（如，update_device_up）。RPC回调处理器带有port ID调用“provisioning_complete”，“L2 agent”实体删除配置（provisioning）块。

当"provisioning_complete"调用删除最后一个记录后，provisioning_blocks模块发出回调PROVISIONING_COMPLETE事件，与port ID一起。ML2中订阅此事件的方法调用update_port_status设置port的状态到ACTIVE

此时正常的通知发向Nova，以允许VM继续运行。

在DHCP或者L2 agent 进入关闭状态的事件中，port将不转换到ACTIVE状态（如L2 agent关闭）。agent必须考虑这种情况，通知服务器在启动过程中进行了所有配置之后连线已经完成。这保证了创建于离线的agent（agents崩溃或重启）的port最终可变为ACTIVE。

考虑到服务器不稳定，有关端口连线的通知必须使用RPC调用，以便agent从服务器获得确认，它必须一直重试，直到端口被删除或成功。

如果ML2驱动程序快速将绑定端口置于ACTIVE状态（例如，在调用update_port_postcommit的后端之后），此修补程序不会对这个过程产生任何影响。