L3 服务插件的风味¶
https://blueprints.launchpad.net/neutron/+spec/multi-l3-backends
此蓝图涵盖了将风味框架引入到树内 L3 服务插件中。通过添加对风味的支持，操作员将能够在同一部署中使用多个 L3 驱动程序。
RFE：https://bugs.launchpad.net/neutron/+bug/1461133
问题描述¶
树内 L3 服务插件仅支持 Neutron 软件路由器（legacy/ha/dvr/ha+dvr）。如果操作员想要使用另一种类型的路由器，则必须更改服务插件，这将导致无法使用参考插件路由器。当前模型未能解决任何特定路由后端仅用于 Neutron 部署中所有逻辑路由子集的使用案例。
更多用例可以在以下 etherpad 中找到：https://etherpad.openstack.org/p/neutron-modular-l3-router-plugin-use-cases
提议的变更¶
将风味支持添加到树内 L3 服务插件中，以便可以根据与给定路由器关联的风味将请求分派到不同的驱动程序。这不会影响 Neutron 之外存在的其他 L3 服务插件。
框图
+---------------------------------------------------------------+
| Neutron Server |
| |
| +----------------------------------------------------------+ |
| | L3 router service plugin | |
| | | |
| | +------------------------------------------------------+ | |
| | | router driver controller | | |
| | +------------------------------------------------------+ | |
| | | |
| | +-----------+ +----+ +---+ +------+ +----------+ | |
| | |single_node| |dvr | |ha | |ha+dvr| | vendor X | ... | |
| | | | | | | | | | | driver | | |
| | +--+--------+ ++---+ ++--+ ++-----+ +----------+ | |
+--+----|------------|-------|------|---------|---------------+-+
| | | | |
|RPC | | | | vendor
| | | | | specific
| | | | | communication
| | | | |
| | | | V
V | | | +------------------+
+---------+ | | | | Proprietron 9000 |
|l3 agent |<-----+-------+------+ +------------------+
+---------+
在风味框架内，有风味和服务提供商。风味通过风味 API 面向用户，它们允许用户选择他们想要的路由器类型（例如“慢速且廉价”）。每个风味都与一个或多个服务配置文件关联。这些服务配置文件定义了一个驱动程序以及要传递给该驱动程序的一些元数据（在它被使用时）。
当用户使用特定风味创建路由器时，风味框架将查找该风味的服务配置文件，并使用关联的驱动程序之一创建路由器。一旦为路由器选择了驱动程序，路由器/驱动程序关联将存储在 DB 中，以便对路由器的任何未来操作都可以查找驱动程序，而无需经过风味框架。
如果用户没有选择风味，他们的路由器将具有 NULL 风味。然后，所选驱动程序将取决于操作员配置的服务提供商，或者在向后兼容的情况下，将根据 HA 和分布式配置标志确定。
目前，风味框架仅支持每个风味一个服务配置文件，因为它缺乏在配置文件之间进行调度的逻辑 [1]。因此，我们最初将仅支持每个风味一个服务配置文件，但这不会阻止将来支持在多个提供商之间进行调度。
风味框架中多个提供商之间的调度不应与路由器调度混淆：风味框架中引用的调度实际上用于确定如果它具有多个关联的服务配置文件，则应为给定风味使用哪个服务提供商。路由器调度用于基于 L3 的基于代理的实现中，多个节点可以托管路由功能，因此服务器需要根据指定的策略（例如随机与基于负载的策略）选择哪个节点。
为了本次努力的目的，路由调度应被视为特定于实现的，并留给驱动程序。换句话说，L3 插件应该不知道路由调度问题，因为驱动程序可能需要或不需要根据实际实现 L3 功能的方式将路由功能调度到节点。
这意味着本次蓝图的范围包括将调度实现细节移动到默认驱动程序中，并让其他驱动程序在需要时负责调度。
DB 操作的责任¶
L3 服务插件将继续负责路由器 DB 对象的 CRUD 操作。这将确保不同风味/驱动程序之间常见字段的一致性。如果驱动程序需要在记录创建到 DB 之前执行输入验证，它可以订阅路由器 PRECOMMIT 事件的验证回调。此外，驱动程序有责任根据 PRECOMMIT 事件调整其自身记录，如果驱动程序需要存储有关路由器的额外信息。
每个驱动程序可能需要分布式协调才能分派和实现路由器操作，因此这些操作的事务性留作驱动程序特定的问题。 可能会根据 [3] 上下文中开发的发现/实验在未来修改此方面
与 ML2 的比较¶
这与 ML2 不同，在于一个重要的方面。对于每个操作，不会调用所有 L3 驱动程序。只有一个驱动程序负责与给定路由器相关的所有操作。调用的驱动程序由在创建路由器时与路由器关联的驱动程序确定。
将路由器与驱动程序关联¶
这种关联是通过以下两种方式之一执行的：或者通过用户明确的风味请求，或者通过分布式/ha 属性和分布式/ha 配置。
驱动程序管理器将加载四个默认驱动程序来表示单节点、ha、分布式和 HA+分布式路由器类型。然后，驱动程序管理器将在没有用户风味请求的情况下选择适当的驱动程序。换句话说，管理器在创建时基于用户选择的风味选择驱动程序，或者如果提供了 HA/DVR 属性，则回退到它们。如果一切都被省略，API 行为将保持不变，并且将创建集中式软件路由器。换句话说，如果将自定义驱动程序加载到默认提供程序旁边，用户必须指定风味才能选择请求的行为。
如果用户请求与风味不兼容的标志（例如 neutron router-create –flavor-id=<ha-id> –distributed=True），将返回错误（例如无效输入）。这可以通过客户端或服务器端解决；但是，服务器端是首选的，因为它使 API 用户行为保持一致。
操作员可以通过在他们的配置中显式定义其他 service_providers 来覆盖默认驱动程序。
操作员决定是否将任何驱动程序作为风味暴露给最终用户选择。与路由器关联的 flavor_id 可以为 null，因此操作员可以通过不定义任何风味（也称为“无味部署”）来维护与当前模型的向后兼容性。
数据模型影响¶
Router 表中将添加一个 flavor_id，并带有对 flavors 表的外键约束。[2] 它将是可为空的，以保留与当前行为的兼容性。
由于服务类型框架已经存在，并且允许将驱动程序与 resource_id 关联，因此不需要对现有表进行其他修改。
REST API 影响¶
现在，所有路由器对象都将具有一个可为空的“flavor_id”属性，该属性指示路由器的风味。此属性也可以在创建/更新调用中使用，以请求特定风味。从 API 扩展的角度来看，建议的框架不会包含任何允许驱动程序将自己的扩展引入 L3 模型的功能，现在和将来都不会。换句话说，将不支持用于扩展插件的编程 API。话虽如此，驱动程序开发时可用的现有机制仍然可以利用。
RPC API 影响¶
基于 L3 代理的解决方案依赖于一个关键的 RPC，允许代理将其状态与服务器同步。此 API (sync_state) 在 l3->dvr->ha->ha+dvr 层次结构中高度专业化。解决混乱是本次努力的长期目标，但是，现在默认软件驱动程序将共享此 RPC 细节，因此将继续依赖 sync_state 操作的现有行为。
一旦框架的第一次迭代完成，将探索解决此方面的策略，以便每个需要共享此 RPC 调用的驱动程序都可以通过组合而不是继承来执行此操作。
向后兼容性¶
风味和服务提供商由操作员定义。但是，我们希望 L3 参考插件在操作员升级时无需采取任何操作即可继续工作。为此，当前的 L3 插件驱动程序将自动将 single_node、ha、dvr 和 dvr+ha 驱动程序注册为服务提供商，以便驱动程序管理器可以像当前系统一样工作。
工作项¶
将风味框架支持添加到现有的 L3 插件中
为单节点、HA、DVR 和 HA+DVR 路由器创建单独的驱动程序
将包含所有类型逻辑的巨大混入分解到主插件中，并将特定于类型的逻辑移动到每个驱动程序中
添加 API 测试以练习风味
