放松资源名称限制¶
https://blueprints.launchpad.net/nova/+spec/relax-resource-name-restrictions
目前，大多数资源名称中允许的字符仅限于 Unicode 字母数字、空格和 [.-_]。应该将其扩展到所有可打印的 Unicode 字符和水平空格。
问题描述¶
资源名称的限制过于严格。在没有充分理由的情况下添加不必要的限制通常是个坏主意。此外，当前的限制已经允许 Unicode，因此任何与 Unicode 相关的顾虑都不应与此蓝图相关联。
用例¶
虽然可能没有立即使用，例如，那个非常有用的 PILE OF POO（一堆便便）作为风味名称的需求，但很难想到人们不应该被允许使用它的理由。
项目优先级¶
无。
提议的变更¶
我们建议放弃对字母数字、空格和 [.-_] 的严格白名单，而是允许所有可打印的三字节 Unicode 字符和水平空格。参考 Unicode 字符类别，允许的字符将是
所有不在
C（其他，包括控制和格式字符）和Z（分隔符）类别中的字符；以及位于
Zs（分隔符，空格）类别中的字符。
对于有合法理由需要限制的字段，仍然可以施加进一步的限制。例如，主机名可以根据 RFC 1178 进行限制，而 RFC 1178 是上述限制的严格子集。
备选方案¶
完全支持四字节字符存在问题，因为 MySQL 存在限制。utf8 字符集仅支持三字节 Unicode，而 utf8mb4 支持完整的四字节 Unicode。但是，MySQL 将键长度限制为 765 字节，这适合 255 个三字节字符串，但仅适合 190 个四字节字符串。因此，为了在 MySQL 中提供完整的四字节 Unicode 支持，我们必须减少任何键字段的长度，这显然是不希望看到的。
使允许的 Unicode 字符宽度可配置（例如，对于使用 PostgreSQL 的安装）比较困难，因为 nova.api.validation.parameter_types，实现命名限制的主要模块，将所有类型定义为模块级变量；使这些可配置会不必要地困难且充满风险。它也可能让在不同环境之间移动的用户感到困惑。
此外，没有人表示有兴趣使用完整的四字节 Unicode 支持；如果有人想稍后实现它，此功能不会阻止该选项。
数据模型影响¶
无。
REST API 影响¶
许多 REST 端点的验证将发生变化；例如，在 Juno 中创建名为“m1.small+”的风味将失败，但一旦此规范实施，就会成功。也就是说，新的允许字符是旧允许字符的严格超集，因此这只应是 Kilo 到 Juno 的问题；在 Juno 上创建的所有资源都可以在 Kilo 上工作。
安全影响¶
无。
通知影响¶
无。
其他最终用户影响¶
无。
性能影响¶
最小。编译后的正则表达式，即使是大型的，也效率惊人。此更改产生的实际性能损失取决于所用名称的长度；较长的名称比较短的名称产生的损失更小。使用五到两百个字符之间的有效和无效名称的随机分布，我发现新方法比旧方法慢约 16%。
虽然 16% 似乎是一个显著的性能影响，但它是当前在现代硬件上以微秒为单位测量的操作的 16%。为了以务实的术语说明性能影响，有人必须创建大约五千万个新实体（例如，五千万个新风味），才能达到因此更改而产生的 10 秒的性能损失（假设 Nova 在我的笔记本电脑上运行，这不建议在生产环境中使用）。
其他部署者影响¶
无。
开发人员影响¶
无。
实现¶
负责人¶
- 主要负责人
stpierre
工作项¶
创建一个新的名称验证正则表达式，允许所有可打印的三字节 Unicode 字符和水平空格。
使所有 JSON Schema 文档对所有服务器名称字段使用
nova.api.validation.parameter_types.hostname进行验证。使所有 JSON Schema 文档对所有其他资源名称使用新的正则表达式进行验证。
依赖项¶
为了使 API 用户能够发现此更改，它依赖于 API 微版本：https://blueprints.launchpad.net/nova/+spec/api-microversions
测试¶
不需要新的 Tempest 测试；需要修改现有的 Tempest 测试，以包含现在在新的、放宽的限制下无效的名称。
当然，也会添加单元测试。
文档影响¶
提及旧资源名称限制的文档需要更新为新的限制。
