更新微版本头¶
https://blueprints.launchpad.net/nova/+spec/modern-microversions
Nova 最先引入了微版本概念。该概念的成功促使其他项目纷纷效仿，但也暴露了原始实现中的一些局限性。其中一个局限性在于微版本头名称的特异性导致在至少两个维度上缺乏灵活性
使用项目名称而不是服务类型与尽可能使用服务类型的跨项目目标不一致。
头名称中名称或类型的放置方式，误导性地表明该类型实际上是头的取值。
API 工作组在新的 微版本规范中解决了这些问题，并制定了相关的避免 头文件泛滥的指南。
问题描述¶
随着新的微版本头规范的出现，Nova 目前不符合规范。
用例¶
作为 OpenStack API 的用户，我期望它们保持一致、连贯和合理。
提议的变更¶
Nova 的微版本处理将被更新，以接受新的请求头样式并发送所需的响应头。具体而言，这意味着在请求中，以下内容将被接受以指示微版本协商
OpenStack-API-Version: compute <the version requested>
在响应中，将发送以下内容
OpenStack-API-Version: compute <the version used>
Vary: OpenStack-API-Version
这些头信息将添加到现有的 X-OpenStack-Nova-API-Version 头信息中，以保持双向兼容性。如果请求中同时存在这两个头信息，则必须优先选择较新的 OpenStack-API-Version 样式头信息。
添加这些头信息，具有讽刺意味的是，需要进行微版本更新。
已经存在一个 microversion-parse 库来促进此更改。
备选方案¶
本规范不试图废弃并最终删除旧的微版本头信息，因为假设这样做弊大于利。在其他情况下，有人担心这会浪费头字节。如果许多人也关心这个问题，我们或许可以找到解决办法。如果存在有用的方法，那将是另一种选择。
数据模型影响¶
无。
REST API 影响¶
没有添加任何 API 方法，但每个请求和响应现在都将包含额外的头信息。幸运的是，进行此更改是集中的。
新头信息中不正确值的处理方式与旧头信息相同（例如，使用 406 响应）。
安全影响¶
无。
通知影响¶
无。
其他最终用户影响¶
python-novaclient 最终需要更新以处理此头信息。如果最低 API 版本高于新微版本头更改设置的阈值，则可以从 novaclient 中删除对旧微版本头信息的支持。
性能影响¶
没有，除非您认为头信息中多出的几个字节相对于性能的其他实际问题来说是一个重要问题。
其他部署者影响¶
如果部署者堆栈中的某个位置存在头信息过滤代理，则它们需要更新以允许新的头信息通过。
开发人员影响¶
无
实现¶
负责人¶
- 主要负责人
cdent
- 其他贡献者
sdague
工作项¶
更新 Nova 的 WSGI 框架以使用 microversion-parse。
更新 WSGI 框架以发送和接收这两个头信息。
更新单元和功能测试。
更新微版本。
依赖项¶
没有，除了上述 microversion-parse，它已经被接受到全局需求中。
测试¶
在测试中，重要的是要确保涵盖使用旧头信息、新头信息、两个头信息以及都不使用头信息的情况。
文档影响¶
api-ref 需要在某个时候更新，以反映新头信息的可用性。这不需要立即进行，因为旧头信息将继续工作，直至永远。
参考资料¶
历史¶
发布名称 |
描述 |
|---|---|
Newton |
引入 |
