按名称搜索风味¶

https://blueprints.launchpad.net/nova/+spec/flavor-search-by-name

允许用户在服务器端按风味名称搜索。

问题描述¶

目前，没有使用 API 按风味名称过滤风味的方法。相反，您必须检索所有风味并手动过滤。这可能代价高昂，尤其是在考虑到“风味爆炸”的情况下。我们希望通过添加对 name 过滤器的支持来解决这个问题。

用例¶

作为客户端工具的开发者，我希望尽可能多地在服务器端进行过滤，以便提高性能并减少不必要的网络流量。

提议的变更¶

修改 GET /flavors API，以添加对新的 name 查询字符串过滤参数的支持。这将支持类似于许多其他现有 API（例如 GET /servers）的正则表达式语法。与这些 API 一样，这将默认进行部分匹配，并且必须使用正则表达式才能获得精确匹配。例如

>>> import openstack
>>> conn = openstack.connect('devstack')
>>> conn.compute.get('/flavors')
>>>
>>> [f['name'] for f in conn.compute.get(r'/flavors').json()['flavors']]
['m1.small', 'ci.m1.small', 'm1.medium', 'ci.m1.medium', 'm2.small', 'ds512M', 'ds1G']
>>>
>>> [f['name'] for f in conn.compute.get(r'/flavors?name=m1').json()['flavors']]
['m1.small', 'ci.m1.small', 'm1.medium', 'ci.m1.medium']
>>>
>>> [f['name'] for f in conn.compute.get(r'/flavors?name=^m1').json()['flavors']]
['m1.small', 'm1.medium']

这将通过重用当前在 _regex_instance_filter 中用于实例的逻辑来实现，参见此处。

虽然我们正在引入一个新的微版本，但我们也会借此机会解决一些技术债务问题，并改进模式

我们将为风味展示（GET /flavors/{flavor_id}）API 将 additionalProperties 设置为 False
我们将从风味创建（POST /flavors）、带有详细信息的风味列表（GET /flavors/detail）和风味展示（GET /flavors/{flavor_id}）API 中删除 rxtx_factor 字段。我们还将从风味列表（GET /flavors）和带有详细信息的风味列表（GET /flavors/detail）API 的有效排序键列表中删除 rxtx_factor。该字段仅由早已删除的 XenAPI 驱动程序支持，并且在现代 Nova 中不起作用。
我们将从带有详细信息的风味列表（GET /flavors/detail）和风味展示（GET /flavors/{flavor_id}）API 中删除 OS-FLV-DISABLED:disabled 字段。从未提供过设置该字段的方法，因此它不起作用。

最后，我们将基于上述项目之一，解决其他模式的技术债务问题

我们将为所有查询字符串模式将 additionalProperties 设置为 False。
我们将将所有操作体限制为 null 值，除非实际需要某个值。

备选方案¶

我们目前必须在客户端执行此操作，这效率较低。我们可以继续这样做。

与其支持正则表达式语法，我们可以选择一个简单的部分匹配过滤器，使用 SQL LIKE 运算符实现。这目前用于 GET /os-hypervisors API 的 hypervisor_hostname_pattern 过滤器（最终由 compute_node_search_by_hypervisor DB API）。这将稍微提高性能，但它将不太具表现力，并且与大多数其他 API 相比，行为差异可能会令人惊讶。

正则表达式支持因我们的官方支持的数据库后端而异，MySQL/MariaDB 和 PostgreSQL，导致不同部署中 API 行为的潜在差异。我们可以调查在这些后端通用的正则表达式子集，并选择仅支持此模式子集。但是，考虑到长期以来对生产部署中 MySQL 的偏见以及其他已经存在此问题的 API 中没有发现问题的现象，这可能是一项复杂且复杂的任务，收益微乎其微。依赖于后端的正则表达式支持是“足够好的”。

数据模型影响¶

没有。 Flavors 模型中的 name 字段已经具有唯一约束，因此已建立索引。此外，我们不计划从 Flavor o.v.o 中删除 rxtx_factor 字段。我们可能希望在未来的版本中从 Flavors 模型中删除该字段，但这应该在未来的版本中完成。

REST API 影响¶

将修改 GET /flavors API，以在请求中添加对新的 name 查询字符串过滤参数的支持
将修改 POST /flavors API，以删除对请求中 rxtx_factor 参数的支持。
将修改所有风味 API，以从响应中删除 rxtx_factor 和 OS-FLV-DISABLED:disabled 字段。
将修改所有当前接受不受限制的查询字符串参数的 API，以限制这些参数。
将修改所有当前在请求主体中限制不受限制的值的操作 API，以仅接受 null。

安全影响¶

无。

通知影响¶

无。

其他最终用户影响¶

openstackclient 和第三方客户端可以在过滤风味时利用这一点。

性能影响¶

没有。客户端将更快，因为他们可以利用服务器端过滤，但由于该字段已建立索引，因此不应影响服务器本身。

其他部署者影响¶

无。

开发人员影响¶

无。

升级影响¶

无。

实现¶

负责人¶

主要负责人: stephen.finucane
其他贡献者: 无

功能联络人¶

功能联络人: stephen.finucane

工作项¶

扩展 API 并按照上述说明重构模式

依赖项¶

无。

测试¶

我们将提供新的单元和功能测试，包括 API 示例测试。

我们将扩展 Tempest 中使用的 Compute API 模式，以反映这些更改。

文档影响¶

更新 API 参考。

参考资料¶

无。

按名称搜索风味