允许 Open vSwitch 代理扩展拥有其 flows

https://bugs.launchpad.net/neutron/+bug/1517903

在 Liberty 版本中，引入了L2 代理扩展和L2 代理扩展管理器。这些扩展在特定事件（特别是端口更新和删除）上被触发，但它们无法与代理的基础资源（例如桥接、flows 等）进行交互。目前正在开发的一些特性（SFC、QoS DSCP、其他特性）需要扩展和运行它的代理之间进行一定程度的协调。

问题描述

扩展需要与运行它们的代理协调的一个主要用例源于 Liberty 周期中添加的 Open vSwitch 代理优雅重启特性。对于此特性，使用每个会话的代理 ID 来区分属于当前代理会话的 flows 和属于先前会话的 flows。问题在于当扩展想要将其自身的 flows 注入到交换机时。由于这些扩展没有办法确定当前的代理 ID 是什么，因此它们无法用它来标记新的 flows，这导致代理在重启时会丢弃所有这些 flows，认为它们是过时的，因为它们“属于”先前的代理会话。

允许每个扩展保留一个代理已知且唯一的 cookie 值，并将其用于自身的 flows，将是第一个参考实现特定于代理的 API，它将通过新的提议机制暴露出来。这将通过在 Open vSwitch 桥接周围的轻量级包装器暴露集成和隧道桥接来实现，该包装器为扩展分配和管理 cookie 值，并使其免受破坏属于其他扩展的 flows 的影响。

一旦扩展的需求得到更好的理解，代理特定的 API 将被扩展。未来计划中的一个特性是更高级别的 flow 管理 API，它将抽象出处理流水线，允许以更受控的方式管理多个感知 flow 的扩展（强制处理顺序，更好地保护其他特性免受行为不端的扩展造成的意外破坏等）。一旦实现了该高级别 API，我们可能会考虑弃用此规范中提出的 API。

请注意，超出本提案范围的额外 API。

提议的变更

拟议的更改将扩展扩展管理器和 L2 代理扩展 API，添加一个可选的特定于代理的 API 对象。扩展管理器将反过来将新的 API 对象传播到每个扩展。需要与运行它的代理交互的扩展将能够通过检查已经传递到其 initialize() 方法的 driver_type 参数来确定正在运行它的代理类型（例如，Open vSwitch、Linuxbridge、SR-IOV 等）。

由于扩展可以维护在 Neutron 树之外，我们应该考虑不要通过后续的代理 API 更改来破坏它们。因此，代理 API 将被视为公共 Neutron API 的一部分，并且会随着对向后兼容性问题的关注而发展。

由于树外代理已经可以依赖扩展机制，因此新的 API 对象参数在扩展管理器和扩展本身中将是可选的。

只有 Open vSwitch 会被更新，以便将相应类型的代理 API 对象传递给 L2 代理扩展。其他代理将在需要时扩展该机制。

作为提案的一部分，Open vSwitch 代理 API 对象将包括两个新的方法，这些方法将返回带有分配给调用扩展的 cookie 值的包装和加固的桥接对象。扩展将能够使用这些包装的桥接对象来设置它们自己的 flows，而代理将依赖于在清理先前代理会话中的过时 flows 时收集这些分配的值。

+-----------+
| Agent API +--------------------------------------------------+
+-----+-----+                                                  |
      |                                   +-----------+        |
      |1                               +--+ Extension +--+     |
      |                                |  +-----------+  |     |
+---+-+-+---+  2  +--------------+  3  |                 |  4  |
|   Agent   +-----+ Ext. manager +-----+--+   ....    +--+-----+
+-----------+     +--------------+     |                 |
                                       |  +-----------+  |
                                       +--+ Extension +--+
                                          +-----------+

与代理 API 对象的交互顺序如下

#1 the agent initializes the agent API object (bridges, other internal state)
#2 the agent passes the agent API object into the extension manager
#3 the manager passes the agent API object into each extension
#4 an extension calls the new agent API object method to receive bridge wrappers with cookies allocated.

调用 #4 也会将分配的 cookies 注册到代理桥接对象。

注意：该提案不涵盖在相应的 openstack-dev@ 邮件列表线程 中建议的主要 flow 表重构。相反，为 Mitaka 选择了一种更简单的方法，以便我们能够解锁对设置自定义 flows 感兴趣的特性，并按照邮件列表提案中的节奏处理表格管理部分。

实现

负责人

  • Ihar Hrachyshka (ihrachys)

  • David Shaughnessy (davidsha)

参考资料