更快的 API 列表响应¶
包含您的 Launchpad 蓝图的 URL
https://blueprints.launchpad.net/neutron/+spec/faster-list-responses
Neutron API 当前为列表响应中的每个元素的每个属性执行策略检查，这会降低响应时间。
问题描述¶
在一些 bug 报告中已经报告了 API 响应缓慢的问题；最近也观察到几个插件存在此问题。此问题的根本原因是，对于响应中返回的每个资源的每个属性，都会执行策略引擎检查。列表响应可能包含大量条目；特别是对于端口而言，当 API 请求使用管理员凭据且没有过滤器执行时，更是如此。在这种情况下，执行的大量策略检查成为一个不可忽视的可伸缩性限制因素。对于列表操作，插件后操作（例如：策略检查）占插件中花费时间的大约 50%。
虽然这个问题不难解决，但其解决方案可能需要更改，从而导致策略引擎行为略有不同。对于列表响应，API 层会将每个条目都通过策略检查，以检查哪些条目对用户完全不可见。但是，它也会将每个属性都通过策略检查，以排除那些对用户不可见的属性，例如普通用户的提供者属性。对每个资源执行此操作可能只有在属性的可见性取决于资源本身的数据时才有意义。例如，可以为名称为“ernest”的所有端口定义一个显示端口绑定属性的策略。这可能看起来很灵活，但实际上毫无意义。列表操作实际上应该为响应中的每个资源返回相同的属性集。
提议的变更¶
策略检查应该仅用于确定要显示的属性列表，并且该属性列表然后应该用于包含在列表操作响应中的每个资源。
为了使之工作，不应该有任何依赖于资源值的属性级别策略；这种限制似乎是合理的。
备选方案¶
替代方案 #1：将属性级别检查移回插件中。在 Havana 发布的之前，软件就是这样工作的。这感觉完全不对，因为理论上，这将允许部署，其 API 行为根据运行的插件而不同。所有的 authZ 工作都应该在通用的 API 层中执行。
替代方案 #2：迭代条目并仅在属性的策略依赖于资源数据时运行策略检查。这将需要我们在策略引擎中目前没有并且可能永远不会拥有的一个内省级别。此外，不同条目在相同的列表响应中最终具有不同的属性，这感觉不对。列表响应就像一个表格，具有固定数量的列。
数据模型影响¶
没有数据模型更改。
REST API 影响¶
没有 API 更改。
安全影响¶
此蓝图不会更改 authZ 处理的逻辑。但是，已经定义了自定义策略以用于属性的部署，这些属性的评估结果取决于正在分析的资源的值，可能会受到影响。
应该记录这一点，因为它可能导致在响应中返回属性，而部署者的意图是隐藏它们。
通知影响¶
没有影响。
其他最终用户影响¶
无需进一步交互。
性能影响¶
预计列表响应提高 33% 的性能。此蓝图的原型代码已经过测试，列表响应包含 4,000 个条目。
其他部署者影响¶
部署者应该知道，依赖于资源值的属性级别策略（例如：字段检查）不应该再执行了。
开发人员影响¶
对开发人员没有影响。合并冲突的可能性有限。
实现¶
负责人¶
- 主要负责人
salvatore-orlando
工作项¶
这将通过一个相对较小的补丁来实现。
依赖项¶
没有依赖关系。
测试¶
正在更改的代码已经由现有的单元和集成测试覆盖。如果需要，可以定义新的单元测试。不需要新的集成测试。
文档影响¶
应该更新 Neutron authZ 策略管理指南。
参考资料¶
无。
