Neutron/Spec-pnetapis-into-core
目录
将提供商网络 API 移入 Quantum 核心
范围
该蓝图的目标是将提供商网络 API 扩展作为官方 'core' Quantum API 的一部分,正如 Grizzly 会议上所同意的那样。
从用户角度来看,几乎不会有任何变化(请参阅 'API' 部分)。插件实现者应注意 '数据模型变更' 部分讨论的变更。
将所有现有插件的代码调整为数据模型变更或其他重构活动,绝对在本蓝图的范围内。
用例
该蓝图不会引入任何新的用例。
实现概述
在许多方面,该蓝图主要涉及代码重构;除了重构之外,最重要的变更涉及 API 和数据模型。
在 API 层,我们计划
- 移除提供商网络属性中的 provider 前缀(目前所有属性都扩展了 network 资源);这与 'provider' 扩展别名即将移除的事实一致,因为代码现在位于核心 API 中。
- 计划是否将 API 升级到 2.1(有关更多信息,请参阅 未解决的问题)
This would require us to maintain both 2.0 and 2.1 APIs, as well as doing the appropriate changes into the API layer for handling multiple versions. 2.0 API would be the 'Folsom' API, whereas version 2.1 would be the 'Grizzly' API. 2.1 will not break backward compatibility.
在 DB 层,该蓝图建议将支持提供商扩展的数据模型类移动到 'base' 模型类中(即:在 quantum.db 包中定义的类)。提供商网络的数据模型类以及 db 逻辑现在作为插件实现的一部分提供。作为积极的副作用,这将允许我们通过删除跨所有插件重复的一些样板代码来缩小代码库。
重构活动
- 将提供商网络扩展的扩展属性、异常和验证器移入 quantum/api/v2 包
- 移除扩展并相应地调整所有插件(从 supported_extension_aliases 中移除 'provider')
- 重构 db 和插件类,以便不再需要显式了解提供商网络扩展的 L2 方法可以简化。
- 将提供商扩展的 '临时' 身份验证检查合并到主策略引擎中
- 根据建议的数据模型变更调整 db 逻辑
数据模型变更
以下类将从插件数据模型中移除并添加到基本模型类中:以下代码来自 OVS 插件。tablename 属性将被移除,因为不再需要
class NetworkBinding(model_base.BASEV2):
"""Represents binding of virtual network to physical realization"""
__tablename__ = 'ovs_network_bindings'
network_id = Column(String(36),
ForeignKey('networks.id', ondelete="CASCADE"),
primary_key=True)
network_type = Column(String(32), nullable=False)
physical_network = Column(String(64))
segmentation_id = Column(Integer) # tunnel_id or vlan_id
从实现的角度来看,是否将提供商网络属性作为 Network 模型的一个属性,还是作为上面所示的独立模型,还有待决定。
此外,将为每个插件提供迁移脚本。这些迁移脚本基本上将移除插件特定的模型类,然后创建一个新的通用模型类,或者将属性添加到 Network 资源。迁移脚本还必须负责迁移现有数据。
配置变量
在本蓝图范围内没有变更。
API
应移除 'provider' 前缀,因为该别名将不再存在。由于这将为 Folsom 用户生成不兼容的变更,因此应通过别名机制仍然允许使用带有 'provider' 前缀的属性。
应在 Grizzly API 参考中弃用该前缀的使用。
测试用例
由于该蓝图不会显著改变 Quantum 服务提供的功能,因此我们预计不会有新的测试用例或测试模块。但是,对于在实现过程中应添加的例程和方法,将提供适当的单元测试。
未解决的问题
此变更是否应将 API 版本升级到 2.1,或者我们是否应继续使用 2.0?升级到 2.1 将允许我们在向 /v2.0/networks 发送请求时继续使用 'provider' 前缀,并在向 /v2.1 发送请求时使用带有或不带有前缀的属性,如 API 变更部分所述。
另一方面,它将增加维护 Quantum API 的 2.0 和 2.1 版本的负担。由于我们目前没有计划淘汰旧的、向后兼容的版本,并添加新的版本,这可能会在长期构成问题。恳请社区反馈以达成共识。如果社区无法达成共识,API 版本应保持为 2.0