L3 插件提供商验证¶
https://blueprints.launchpad.net/neutron/+spec/l3-svcs-vendor-validation
目前，终端用户选择的验证与参考实现紧密绑定。因此，替代提供商在资源已经持久化之后，才能验证终端用户配置选择。
问题描述¶
当 Neutron 收到 L3 服务请求时，它会调用相应的服务插件，该插件会验证并持久化请求的信息（通常在一个步骤中完成）。最后，插件会调用服务驱动程序来应用更改。
在应用阶段，提供商的服务驱动程序才有机会对请求采取行动。如果提供商有额外的约束条件，它可以拒绝该请求，但资源已经会先被持久化。
例如，在使用选择 v2 的 IKE 策略创建 VPN IPsec 站点连接时，连接将通过验证，被持久化，并调用服务驱动程序。对于目前通过其 REST API 不支持 v2 的 Cisco CSR 而言，服务驱动程序可以在应用期间引发异常。但是，连接已经创建并持久化了。
此外，如果服务驱动程序有需要执行的持久化操作，则必须在应用阶段执行。
提议的变更¶
本提案旨在将验证分解为单独的函数，并提供一种方式，让提供商服务驱动程序可以扩展或覆盖验证逻辑（如果需要）。
对当前验证的研究表明，为了处理多个客户端同时更改相同资源的情况，必须在持久化步骤期间完成验证。事务将强制一致性。
计划的方法是在服务驱动程序抽象基类中创建默认验证逻辑，并在持久化期间选择活动服务驱动程序并调用其验证方法。
服务驱动程序可以在默认逻辑之前、之后或代替默认逻辑执行验证，或者不提供验证方法，则将执行抽象基类中的默认验证。
目标是将相同的提案推广到所有 L3 服务插件。
这将是一个结构性更改，而不是行为性更改。
在 Juno 会议期间，讨论了使用 TaskFlow 包来管理验证、持久化和应用操作的处理流程。
需要对 TaskFlow 进行更多研究，但无论如何，验证逻辑都应与持久化逻辑分离，并且可以作为初步工作完成。
备选方案¶
另一种方法是将资源状态/状态标记为ERROR，但数据库仍然与请求操作的实际状态不一致。
数据模型影响¶
预计不会对数据库模式或操作进行任何更改，除了现在可以准确反映资源的实际状态。
REST API 影响¶
预计不会对 REST API 进行任何更改。
安全影响¶
无。
通知影响¶
没有？
其他最终用户影响¶
无。
性能影响¶
预计没有显著的性能影响。
其他部署者影响¶
无。
开发人员影响¶
提供商希望更新其服务驱动程序，以利用新的验证和拒绝请求的能力，具体取决于提供商的功能。
实现¶
负责人¶
- 主要负责人
pmichali
- 其他贡献者
任何人
鉴于 L3 服务的范围和数量，将非常感谢额外的贡献者！
工作项¶
为每个 L3 服务创建和更新 API
重构数据库功能 * 提取验证逻辑并移动到服务驱动程序抽象基类 * 添加钩子以调用现在在服务驱动程序中的验证逻辑
如果需要，将验证方法添加到提供商的服务驱动程序
根据结构性更改更新单元测试
注意：验证逻辑的分离可以独立地在每个 L3 服务上完成（没有依赖关系），并且可以根据需要完成（例如，仅在多个实现具有不同验证需求的情况下），如果需要的话。
依赖项¶
无
测试¶
由于这是一个结构性更改，预计不需要额外的 tempest 测试。
单元测试需要修改，主要是由于方法名称更改，但也可能由于逻辑的更好隔离而更改。 检查验证和持久化（或执行持久化以检查验证）的测试可以拆分为更隔离的测试用例。 这应该减少测试用例中的重叠（可能消除一些测试），更好的隔离，以及可能更好的性能（不必执行多个任务来测试某些功能）。
文档影响¶
无。
参考资料¶
目前没有。
