本文主要是介绍OpenStack之Provisioning Blocks管理复杂对象的状态，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
我们使用对象的STATUS字段表示资源是否可用，如果设置为ACTIVE，外部系统认为可以安全的使用此资源。如果仅有一个实体负责配置（provisioning）给定的对象，很容易知道合适将status设置为ACTIVE。当实体完成配置（provisioning），我们就更新STATUS到ACTIVE。尽管如此，在Neutron内部由许多资源需要在可用之前由多个异步的实体进行配置（provisioning），所以管理status到ACTIVE状态的转变变得更加复杂。为处理此情况，Neutron增加了 provisioning_blocks 模块用于跟踪正在配置（provisioning）资源的实体。
ML2模块中的主要示例是：L2 agents 和 DHCP agents。当port被创建并绑定到主机时，它处于DOWN状态。L2 agent需要为port建立流flows，安全组规则等，DHCP agent需要建立port的IP和MAC地址的预留绑定。在转到ACTIVE之前，两个agent必须完成他们的工作，或者port的使用者（如 Nova）可能尝试使用此port，而得不到连通性。为解决此问题，provisioning_blocks模块用来跟踪每个agent的配置（provisioning）状态，对象的status只有在两个agent完成时才会更新。
High Level View
要使用provisioning_blocks模块，即当对象的status转换为ACTIVE之前，需要另外的实体完成工作，必须添加配置（provisioning）组件。通过为每个实体调用方法add_provisioning_component来实现。当每个实体完成配置（provisioning）对象后，provisioning_complete被调用移除配置（provisioning）块。
当最后一个配置块被移除后，provisioning_blocks模块将触发回调通知，其中包含对象资源类型的对象ID，事件为PROVISIONING_COMPLETE。此事件的订阅者现在可更新对象的status到ACTIVE状态，或者执行其它需要的动作。
通常的状态转变过程如下:
- 请求创建对象
- Neutron服务器逻辑决定哪些实体需要去配置（provision）此对象，并为此对象的所需实体添加配置（provisioning）组件
- 发送通知到实体，以便它们开始工作.
- 对象返回给API调用者，status为DOWN（或 BUILD）状态.
- 每个实体在完成对象配置（provisioning）之后通知服务器。Neutron服务器为每个完成的实体调用provisioning_complete
- 当为最后一个实体调用了provisioning_complete之后，provisioning_blocks模块将发出表示对象以及配置（provisioning）完成的事件。
- 服务器上的此事件订阅者将更新对象的status到ACTIVE状态，表示它已经配置完成
关于更精确的示例，参见以下章节.
ML2, L2 agents, 和 DHCP agents
ML2使用provisioning_blocks模块防止在L2 agent和DHCP agent完成port连接工作之前，将port的status转换到ACTIVE状态。
当port创建或更新，以下步骤注册DHCP agent的配置（provisioning）块：
- 从port的fixed_ips字段抽取出来 subnet_ids，之后ML2检查DHCP是否在其中的subnet上启用。
- 查找承载网络的DHCP agent配置以确保至少有一个足够新的可报告其完成了port预留。
- 以上的两个条件有一个失败的话，DHCP agent的配置（provisioning）块将不会添加，并且任何现存的阻塞此port的DHCP agent将被清除，以保证port不会阻塞在等待一个不会发生的事件。
- 如果以上的条件成立，port的配置（provisioning）块被添加在“DHCP”实体下。
当port创建或更新，以下步骤注册L2 agent的配置（provisioning）块:
- 如果port没有绑定，不做任何事，因为我们还不知道是否会涉及到L2 agent，所以必须等待绑定端口的更新.
- 一旦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的后端之后），此修补程序不会对这个过程产生任何影响。
这篇关于OpenStack之Provisioning Blocks管理复杂对象的状态的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
