VIF端口配置版本化对象和驱动插件库¶
https://blueprints.launchpad.net/nova/+spec/os-vif-library
定义一个独立的 os-vif python 库，灵感来自 os-brick，为从 neutron 传递到 nova 用于 VIF 端口绑定的数据提供版本化的对象模型，并提供一个 API，允许厂商提供自定义的插拔操作，供 Nova 执行。
问题描述¶
当将 VIF 插入虚拟机实例时，Nova 和 Neutron 之间存在通信，以获取端口绑定元数据的字典。Nova 将此传递给 virt 驱动程序，后者有一组用于处理不同 VIF 类型的类。在 libvirt 的情况下，每个类都有三种方法，一种用于构建 libvirt XML 配置，一种用于执行与插入 VIF 相关的宿主机操作系统配置任务，一种用于执行与拔出 VIF 相关的宿主机操作系统配置任务。
当前，每当创建一个新的 Neutron 机制驱动程序时，就会导致定义一个新的 VIF 类型，并向 libvirt 驱动程序添加一个新的 VIF 类来支持它。由于供应商的多样性，随着时间的推移，需要处理的 Neutron 机制数量可能是无限的。相反，不同的 libvirt XML 配置数量相对较少且定义明确。随着 QEMU 获得新的网络后端，有时会定义新的 libvirt XML 配置，但这比较少见。在 libvirt 的 VIF 驱动程序今天支持的 15 种不同的 VIF 类型中，只需要 5 种不同的 libvirt XML 配置。这些在
此架构的问题在于 Nova libvirt 维护者必须维护 VIF 驱动程序中的插拔代码，而实际上这些代码是由 Neutron 机制的需求定义的。这阻止了 Neutron 项目/厂商在 Nova 中进行同步更改的情况下添加新的 VIF 类型。
第二个相关问题是，Nova 和 Neutron 之间传递的用于 VIF 端口绑定的数据格式定义得比较松散。传递的信息没有版本控制，也没有就不同字段的含义达成正式规范。这些数据既用于生成 libvirt XML 配置，又用于控制插拔操作的逻辑。
用例¶
总体用例是促进新 Neutron 机制的创建，消除 Nova 作为工作流程中的瓶颈。在常见情况下，新功能完全可以在 Neutron 代码库（或机制特定代码库）中实现，而无需添加/更改 Nova 中的代码。
提议的变更¶
受 Cinder 项目启动的 os-brick 库的启发，该提案涉及创建一个新的库模块，该模块将由 Neutron 和 Nova 团队共同开发，供两个项目使用。
该提案描述了一种具有以下高级特征和职责划分的架构
定义 VIF 类型和相关的配置元数据。
由 Nova 和 Neutron 核心评审团队共同拥有
代码共享在 os-vif 库中
确保核心团队对 REST API 上的数据拥有 100% 的控制权
设置计算主机操作系统网络堆栈
由 Neutron 机制供应商团队拥有
代码由机制供应商分发
允许供应商在常见情况下创新，而不会对 Nova 开发人员造成瓶颈。
在不常见的情况下，如果需要新的 VIF 类型，仍然需要修改 os-vif，并获得 Nova 和 Neutron 核心团队的批准。
配置来宾虚拟机的 VIF，例如 libvirt XML
由 Nova virt 驱动程序团队拥有
代码作为 Nova virt / VIF 驱动程序的一部分分发
确保 hypervisor 驱动程序保留对如何配置来宾实例的完全控制权
请注意，虽然下面的描述经常引用 Nova libvirt 驱动程序，但该提案不被认为特定于 libvirt。所有其他 virt 驱动程序都存在相同的 VIF 类型支持概念和要求。它们只是支持比 libvirt 少得多的不同 VIF 类型，因此问题不会那么明显。
该库将使用 oslo.versionedobjects 模块，以便正式定义一组对象来描述 VIF 端口绑定数据。这些对象中的数据将被序列化为 JSON，以便在 Neutron 和 Nova 之间传输，就像当前使用的字典一样。区别在于，通过使用 oslo.versionedobjects，我们可以获得正式规范，并能够以更具未来保障性的方式随着时间的推移扩展和修改对象。可以想象一个基本对象
from oslo_versionedobjects import base
class VIFConfig(base.VersionedObject)
# Common stuff for all VIFs
fields = {
# VIF port identifier
id: UUIDField()
# Various common fields see current
# nova.network.model.VIF class and related ones
...snip...
# Name of the class used for VIF (un)plugging actions
plug: StringField()
# Port profile metadata - needed for network modes
# like OVS, VEPA, etc
profile: ObjectField("VIFProfile")
}
这个基本对象定义了所有不同 VIF 端口绑定类型共有的字段。目前，这些属性在 nova.network.model 中的 VIF 类或 Neutron 中的等效类中详细说明。
这里的一个补充是一个“plug”字段，它将是用于执行宿主机操作系统上特定于供应商的插拔工作的类的名称。Nova 将通过基于 stevedore 的注册机制确定“plug”字段的有效值。Nova 可以将此信息传递给 Neutron，以便机制也知道 Nova 计算节点上安装了哪些插件。标记插件类版本也将是必需的，以便在 Neutron 机制版本可能比 Nova 安装的插件更新时进行升级。
这个“plug”字段将 VIF 类型与特定于供应商的工作解耦，从而允许 VIFConfig 类的数量保持相对较小且有限的大小，同时仍然允许实现任意数量的 Neutron 机制。例如，从当前列表中的 VIF 类型
我们可以看到，IVS、IOVISOR、MIDONET 和 VROUTER 都使用相同的 libvirt type=ethernet 配置，但不同的插拔脚本。同样，在 type=bridge 之间也存在显着重叠，但插拔脚本不同。
将根据当前传递的信息的不同部分创建各种 VIFConfig 子类。注意，这并没有涵盖所有当前的 VIF_TYPE_XXX 变体，因为其中一些变体具有相同的配置参数要求，并且仅在插拔操作方面有所不同，因此之前关于“plug”类名称的说明。所有现有的 VIF 类型都将被视为遗留类型。这些各种配置类将定义一组全新的现代 VIF 类型。在许多情况下，它们将类似于现有的 VIF 类型，但关键的区别在于数据序列化格式，它将使用 oslo.versionedobject 序列化而不是字典。通过定义一组全新的 VIF 类型，我们可以轻松地让 Nova 与 Neutron 协商使用新类型，并确定是否能够使用基于对象的新 VIF 类型或遗留的匿名字典类型。
以下依赖的规范描述了一种在 Nova 创建 VIF 端口时将支持的 VIF 类型列表传达给 Neutron 的机制。
该规范中描述的内容需要进行一些改进。与其只是一个 VIF 类型列表，不如说是一个 VIF 类型及其版本的列表。这将允许 Neutron 将 VIF 对象数据回退到旧版本，以防 Neutron 运行的是比 Nova 计算主机上安装的 os-vif 库更新的版本。其次，除了 VIF 类型列表之外，Nova 还需要提供一个已安装插件及其版本的列表。
因此，将定义以下一组对象来表示新的 VIF 类型。预计将使用 oslo VersionedObject 基类定义的“obj_name()”API 的结果作为 VIF 类型名称。这与遗留 VIF 类型名称提供了清晰的命名空间分离。
class VIFConfigBridge(VIFConfig):
fields = {
# Name of the host TAP device used as the VIF
devname: StringField(nullable=True)
# Name of the bridge device to attach VIF to
bridgename: StringField()
}
class VIFConfigEthernet(VIFConfig):
fields = {
# Name of the host TAP device used as the VIF
devname: StringField()
}
class VIFConfigDirect(VIFConfig):
fields = {
# Source device NIC name on host (eg eth0)
devname: StringField()
# An enum of 'vepa', 'passthrough', or 'bridge'
mode: DirectModeField()
}
class VIFConfigVHostUser(VIFConfig):
fields = {
# UNIX socket path
path: StringField()
# Access permission mode
mode: StringField()
}
class VIFConfigHostDevice(VIFConfig):
fields = {
# Host device PCI address
devaddr: PCIAddressField()
# VLAN number
vlan: IntegerField()
}
注意，上述类中列出的属性尚未完全全面。在实施时，将对当前 VIF 代码进行更彻底的分析，以确保涵盖所有必需的属性。
此列表基于此 wiki 页面中识别的信息
其中一些适用于其他 hypervisor，但可能还需要一些 vmware/hypervisor/xenapi 特定的配置子类。此规范目前不尝试枚举这些内容，但它们将是同样简单且有限的集合。
仔细观察的人会看到在前面显示的“VIFConfig”类中引用了一个“VIFProfile”对象。此对象对应于可以在 <portprofile>…</portprofile> XML 块中提供的数据。当 VIF 连接到 OpenVSwitch 或使用两种 VEPA 模式之一时，这是必需的数据。可以将此数据内联地提供在 VIFConfig 子类中，但有一些情况是相同的数据需要由不同的 VIF 类型使用，因此将其分解为单独的对象可以更好地重用，而不会增加 VIF 类型的数量。
class VIFProfile(base.VersionedObject):
pass
class VIFProfile8021QBG(VIFProfile):
fields = {
managerid: IntegerField(),
typeid: IntegerField()
typeidversion: IntegerField()
instanceid: UUIDField()
}
class VIFProfile8021QBH(VIFProfile):
fields = {
profileid: StringField()
}
class VIFProfileOpenVSwitch(VIFProfile):
fields = {
interfaceid: UUIDField()
profileid: StringField()
}
最后，如前段所述，该库还需要定义一个接口，以启用执行插拔操作。这是一个相当简单的抽象 python 类
class VIFPlug(object):
VERSION = "1.0"
def plug(self, config):
raise NotImpementedError()
def unplug(self, config):
raise NotImpementedError()
此处传递的“config”参数将是上面定义的 VIFConfig 版本化对象的实例。
每个 Neutron 供应商机制将至少提供一个此 VIFPlug 类的子类。这些子类实现不需要成为 os-vif 库的一部分。机制供应商预计会独立分发它们，从而保持 neutron 开发的分散性。预计供应商将为他们需要能够与 Nova hypervisor 集成的每个 hypervisor 提供一个单独的 VIFPlug 实现，因此必须在 Nova 请求创建 VIF 端口时将 Nova hypervisor 信息提供给 Neutron。VIFPlug 类必须通过 stevedore 机制向 Nova 注册，以便 Nova 可以识别其可用的实现，并因此验证来自 Neutron 的使用特定插件的请求。它还允许 Nova 告诉 Neutron 可以使用哪些插件。插件也将进行版本控制，以便清楚地了解 Neutron 将执行哪个版本的插件逻辑。
不允许供应商定义新的 VIFConfig 子类，这些子类将由 os-vif 库维护者（即 Neutron 和 Nova 团队）控制，因为任何添加到通过 REST API 传递的数据的补充都必须经过项目维护者的审查和批准。因此，对新 VIFConfig 类的提案将提交到 os-vif 存储库，在那里将由参与该库工作的 Nova 和 Neutron 代表共同审查。
因此，当供应商希望创建一个新的机制时，他们首先决定需要定位哪些 VIFConfig 实现，并用有关其 VIF 的必要信息填充它。这些信息足以让 Nova hypervisor 驱动程序配置来宾虚拟机。在实例化 VIFConfig 实现时，Neutron 供应商将设置“plug”属性，以引用他们使用供应商特定逻辑实现的 VIFPlug 子类的名称。供应商 VIFPlug 子类必须安装在 Nova 计算节点上，以便 Nova 可以加载它们。
当 Nova 询问 Neutron 创建 VIF 时，neutron 返回序列化的 VIFConfig 类，Nova 加载它。Nova 计算管理器将其传递给 virt 驱动程序实现，该实现实例化由“plug”属性定义的类。然后，它将根据是附加 VIF 还是将其分离到来宾实例，调用“plug”或“unplug”方法。hypervisor 驱动程序然后将使用 VIFConfig 类中存储的数据配置来宾虚拟机。
当新的 Nova 与旧的 Neutron 通话时，它显然会以现有的字典格式接收端口绑定数据。Nova 必须具有一些兼容性代码才能支持以这种格式消耗数据。现有的 libvirt 驱动程序插拔方法也需要转换为 VIFPlug 子类。这样，新的 Nova 就可以处理旧的 Neutron 知道的所有预先存在的 VIF 类型，而不会损失任何功能。
当旧的 Nova 与新的 Neutron 通话时，Neutron 必须以现有的遗留端口绑定格式返回数据。为了使之工作，Nova 和 Neutron 之间需要进行协商，以选择使用新的 VIFConfig 对象模型。需要显式选择加入，当旧的 Nova 与新的 Neutron 通话时，Neutron 将知道要返回 Nova 仍然可以理解的遗留格式数据。显而易见的含义是，任何依赖于新的 VIFConfig 对象模型的全新 Neutron 机制将无法与遗留 Nova 部署一起工作。这不被认为是一个重要的问题，因为 Neutron/Nova 版本的不匹配只是云在从 Kilo 到 Liberty 升级过程中临时存在的问题。
为了帮助理解这与当前设计的变化，比较对象之间的关系很有帮助。当前，Neutron 机制、vif 类型和 virt 驱动程序插件之间主要存在 1:1 映射。因此，每个新的 Neutron 机制通常需要一个新的 VIF 类型和 virt 驱动程序插件。
在这个新的设计中，将存在以下关系
VIF 类型 <-> VIFConfig 类 - 1:1 - VIFConfig 类是每个 VIF 类型的直接表示 - VIF 类型只是用于表示数据的类的名称。
Neutron 机制 <-> VIF 类型 - M:N - 单个机制可以使用一个或多个 VIF 类型，具体选择在运行时基于使用场景进行。多个机制可以使用相同的 VIF 类型
VIF 类型 <-> VIF 插件 - 1:M - 单个 VIF 类型可以与多个插件一起使用。例如，许多机制将使用相同的 VIF 类型，但每个机制都提供自己的插件实现用于宿主机操作系统设置
VIF 插件和 VIF 类型之间的分割是实现限制随着时间的推移创建的新 VIF 类型数量的关键。
备选方案¶
什么都不做。继续使用当前的方法，即每个新的 Neutron 机制都需要更改 Nova hypervisor VIF 驱动程序以支持其供应商特定的插拔操作。这不会让任何人满意。
返回到以前的方法，即允许加载 libvirt 的树外 VIF 驱动程序插件。由于许多原因，这不可取。
配置 libvirt 来宾包括两个部分，通常称为后端配置（即宿主机）和前端配置（即来宾看到的内容）。前端配置是 libvirt 驱动程序需要直接控制的内容，以便支持与后端配置无关的各种功能。
此外，libvirt 驱动程序有一组用于表示来宾 libvirt XML 配置的类，这些类能够表示任何 VIF 配置。这些被认为是 libvirt 内部实现的一部分，而不是稳定的 API。
第三，libvirt VIF 驱动插件 API 在过去已经发生过变化，未来也可能再次变化，并且传递给它的数据是来自端口绑定的一个定义不清的字典。
出于这些原因，强烈希望不要将当前 libvirt VIF 驱动类的整个实现交给外部第三方。
尽管如此，本规范实际上将事情回到了与之前方法非常相似的状态。本规范的关键区别和优势在于，它定义了一组版本化的对象来保存传递给第三方 VIFPlug 实现的数据。外部 VIFPlug 实现仅负责主机操作系统设置任务 - 例如插拔操作。libvirt 驱动程序保留对客户机配置的控制权。VIFPlug 驱动程序与 libvirt 超visor 驱动程序的内部实现和 API 设计隔离。共同点是 Neutron 供应商能够保留对其插拔任务的控制权，而不会受到 Nova 的干扰。
保留当前的 VIF 绑定方法，但包含一个可执行程序（脚本）的名称，Nova 将调用该程序来执行插拔操作。
这与本规范中的提议大致相同，只是将进程内执行 python 代码替换为进程外执行（shell）脚本。对于脚本，必须将 VIF 端口绑定中的数据提供给脚本，并且提议使用环境变量。如果数据都是标量，这还可以接受，但如果需要提供非标量结构化数据，例如字典/列表，那么使用环境变量的方法将非常难以处理。
VIF 脚本方法还涉及创建一些正式的版本化对象来表示端口绑定数据，但这些对象位于 Nova 内部。由于 Neutron 同样需要表示 VIF 端口绑定数据，因此如果我们可以拥有一个外部 python 模块，该模块定义了用于表示端口绑定数据的版本化对象，并且可以在 Nova 和 Neutron 之间共享，则会更好。
我们认为，通过定义一组正式的版本化对象来表示 VIF 端口绑定数据，以及一个用于插拔操作的 python 抽象类，我们可以实现 Nova 和 Neutron 之间边界的严格、干净且易于扩展的接口，从而避免通过环境变量序列化数据时出现的一些问题。例如，VIFPlug 子类仍然可以访问定义良好的 VIFConfig 类属性，而不必解析环境变量。
按照本规范，但将所有 VIFConfig 类保留在 Nova 中，而不是创建单独的 os-vif 库。主要的缺点是 Neutron 最终需要创建其自身 VIFConfig 类的副本，并且需要在 Nova 和 Neutron 之间就通过 REST API 传递的 VIF 端口绑定元数据达成一致的序列化格式。通过将 VIFConfig 类放在 Nova 和 Neutron 可以直接使用的库中，我们可以确保这两个应用程序都具有统一的对象模型，并可以利用标准的 oslo.versionedobject 序列化格式。这为 Neutron/Nova 带来了定义明确的 REST API 数据格式，用于它们之间传递的数据。
将 VIF 插拔的责任转移到 Neutron。这将要求 Neutron 在每个计算节点上提供一个代理，负责处理插拔操作。该代理必须具有插件 API，以便每个 Neutron 机制可以为其插拔逻辑提供自己的逻辑。此外，该代理还必须处理分阶段升级，其中旧代理与新的 Neutron 配合使用，或者新代理与旧的 Neutron 配合使用。仍然需要完成工作以正式化 Neutron 和 Nova 之间传递的 VIF 配置数据，以用于配置客户机实例。因此，这种替代方案最终与本规范中描述的内容非常相似。当前提议可以简单地被认为是提供这种架构，但代理实际上内置于 Nova 中。鉴于 Neutron 和 Nova 的当前实现，利用 Nova 作为计算节点上的“代理”是一种更轻松的方法，没有明显的缺点。
数据模型影响¶
数据库数据模型没有变化。
REST API 影响¶
这项工作需要上述规范，以允许 Nova 将其支持的 VIF 类型细节传递给 Neutron
对于现有的“遗留”VIF 类型，Neutron 返回的数据格式不会改变。
对于新的“现代”VIF 类型，Neutron 返回的数据格式将使用 oslo.versionedobjects 序列化格式，而不是仅仅序列化一个普通的 python 字典。换句话说，数据将是以下 API调用的结果
jsons.dumps(cfg.obj_to_primitive())
其中 cfg 是 VIFConfig 版本化对象。因此，此 JSON 数据是正式指定的和版本化的，从而提高了未来版本中演进此数据类型的能力。
在向后兼容性方面，有以下场景需要考虑
旧 Neutron (Kilo)，新 Nova (Liberty)
Nova 在请求中添加了额外的信息，告诉 Neutron 它支持哪些 VIF 类型和插件。Neutron 不了解这些信息，因此忽略它，并返回其中一个遗留 VIF 类型。Nova libvirt 驱动程序将此遗留 VIF 类型转换为现代 VIF 类型，使用其内置的后向兼容插件之一。因此，与旧 Nova 相比，不应有任何功能损失
新 Neutron (Liberty)，旧 Nova (Kilo)
Nova 在请求中没有添加任何信息，告诉 Neutron 它支持哪些 VIF 类型。Neutron 假定 Nova 仅支持遗留 VIF 类型，因此以该格式返回数据。Neutron 不尝试使用现代 VIF 类型。
新 Neutron (Liberty)，新 Nova (Liberty)
Nova 在请求中添加了额外的信息，告诉 Neutron 它支持哪些 VIF 类型和插件。Neutron 机制查看此信息，并决定使用哪个 VIF 类型 + 插件来处理端口。Neutron 返回一个序列化的 VIFConfig 对象实例。Nova libvirt 直接使用其现代代码路径来处理 VIF 类型
更近期的 Neutron (Mxxxxx)，较新的 Nova (Liberty)
Nova 在请求中添加了额外的信息，告诉 Neutron 它支持哪些 VIF 类型和插件。Neutron 看到 Nova 仅支持 VIFConfigBridge 版本 1.0，但它有版本 1.3。Neutron 因此使用 obj_make_compatible() 将对象降级到版本 1.0，然后再将 VIF 数据返回给 Nova。
较新的 Neutron (Liberty)，更近期的 Nova (Mxxxx)
Nova 在请求中添加了额外的信息，告诉 Neutron 它支持哪些 VIF 类型和插件。Neutron 只有版本 1.0，但 Nova 支持版本 1.3。Nova 可以轻松处理版本 1.0，因此 Neutron 可以只返回版本 1.0 格式的数据，Nova 加载并运行它。
安全影响¶
由供应商提供的外部 VIFPlug 类可以在计算节点上运行任意代码。这与当前情况没有太大的安全风险差异，当前 libvirt VIF 驱动程序的插拔方法实现会在计算主机上运行相当任意的一组命令。一个区别是 Nova 核心团队将不再负责审查该代码，因为它将由 Neutron 机制供应商独占维护。
虽然供应商可以向其插件中添加恶意代码是显而易见的。但这并不是完全的自由，云管理员必须采取明确的行动才能将此插件安装到计算节点上，并通过 stevedore 正确地注册它。因此，这并不能允许 Neutron 执行任意代码。
通知影响¶
无
其他最终用户影响¶
无
性能影响¶
无
其他部署者影响¶
部署新的 Neutron 机制时，将包含一个 python 模块，该模块必须部署到每个计算主机上。这提供了主机操作系统插拔逻辑，将在将 VIF 添加到客户机时运行。
换句话说，虽然当前部署机制的用户会执行
pip install neutron-mech-wizzbangnet
在网络主机上，在新系统中他们还必须运行
pip install nova-vif-plugin-wizzbangnet
任何希望与此机制集成的计算节点。
预计各种用于部署 openstack 的供应商工具能够自动化此额外要求，因此云管理员不会受到此影响。
开发人员影响¶
当 QEMU/libvirt（或其他 hypervisor）发明一种配置虚拟机网络的新方法时，可能需要定义一个新的版本化对象，该对象位于 Neutron 和 Nova 之间共享的 os-vif 库中。这将涉及定义 VIFConfig 的子类，然后在 Nova libvirt 驱动程序中实现逻辑来处理这种新的配置类型。根据 QEMU 中此类添加的历史频率，预计这种情况很少发生。
当供应商希望实现新的 Neutron 机制时，他们必须提供 VIFPlug 类的实现，该类的抽象接口在 os-vif 库中定义。供应商特定的实现不需要包含在 os-vif 库本身中 - 它可以由供应商自行分发和部署。这使供应商无需与 Nova 进行锁定步骤更新即可支持其产品。
实现¶
负责人¶
- 主要负责人
待定
其他贡献者
Daniel Berrange <berrange@redhat.com> irc:danpb Brent Eagles <beagles@redhat.com> irc: beagles Andreas Scheuring Maxime Leroy Jay Pipies irc: jaypipes
工作项¶
在 openstack 和/或 stackforge 中创建一个新的 os-vif python 模块
使用 oslo.versionedobjects 实现 VIFConfig 抽象基类作为版本化对象。
同意并定义需要支持的最小 VIF 配置集。这大约等于不同 libvirt XML 配置的数量，再加上一些用于其他 virt hypervisor 的配置
为步骤 3 中标识的每个配置创建 VIFConfig 子类。
定义 VIFPlug 抽象基类，供 Neutron 机制供应商实现
扩展 Neutron，使其能够询问机制，以遗留字典格式或作为 VIFConfig 对象实例返回 VIF 端口数据
扩展 Nova/Neutron REST 接口，以便 Nova 能够请求使用 VIFConfig 数据格式
将代码添加到 Nova，以将遗留字典格式转换为新的 VIFConfig 对象格式，以实现与旧 Neutron 的向后兼容
将 Neutron 机制转换为能够使用新的 VIFConfig 对象模型
盈利
依赖项¶
关键依赖项是在设置新的 os-vif python 项目以及定义 VIFConfig 对象模型和 VIFPlug 接口方面，Nova 和 Neutron 团队之间的协作。
还存在一个依赖项，即同意如何扩展 Neutron 中的 REST API，以允许 Nova 请求使用新的数据格式。这在更多细节中讨论于
虽然其中一些方面可能需要更新以考虑本规范中的提议
完成这些之后，Nova 和 Neutron 团队可以独立地进行各自的工作项。
测试¶
当前的 gate CI 系统包含对某些 Neutron 机制的覆盖。一旦 Neutron 和 Nova 都支持新的设计，当前的 CI 系统将自动开始测试其操作。
对于当前 CI 未覆盖的 Neutron 机制，预计各自的供应商将承担测试其自身实现的责任，就像当前第三方 CI 的情况一样。
文档影响¶
主要的文档影响不是面向用户的。所需的文档将全部面向开发人员，因此可以作为各自 python 项目中的简单文档来完成。
将需要一些特定的发布说明，以告知云管理员升级期间的注意事项。特别是，在升级 Nova 时，希望部署一个或多个 Nova VIF 插件，以匹配当前正在使用的 Neutron 机制。如果他们未能部署插件，则 Nova/Neutron 协商应确保 Neutron 继续使用遗留 VIF 类型，而不是切换到现代 VIF 类型。
参考资料¶
关于 VIF 端口绑定类型的 Neutron 和 Nova 之间的协商的提议。这是本规范的前提
将 VIF 脚本引入现有 VIF 端口绑定数据的替代提议。本规范已过时。
再次将 hypervisor VIF 驱动程序插件完全外包给第三方的替代提议。本规范已过时。
Jay Pipes 建议的库的基本实现
Jay 的设计的变体，它更接近于本规范中描述的内容
历史¶
发布名称 |
描述 |
|---|---|
Liberty |
引入 |
