vendordata 重启，Ocata 中剩余工作¶
https://blueprints.launchpad.net/nova/+spec/vendordata-reboot-ocata
在 Newton 中，Nova 团队实现了一种新的方式，让部署者通过 configdrive 和元数据服务器向实例提供 vendordata。有一些较小的项目没有在 Newton 中完成，我们需要最终确定它们。
您可以阅读 Newton 中的规范以获取有关 vendordata 的更多详细信息。它位于
https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/vendordata-reboot.html
问题描述¶
请参阅 Newton 规范，以获取对 Newton 提出的工作的完整描述。一般来说，以下内容已经实现
vendordata v2 的初始实现
功能测试
SSL 证书验证支持
用例¶
以下项目将在 Ocata 中实现，按照本文档中的顺序进行。
提议的变更¶
Keystone token 变更¶
对于 Nova 元数据服务和 vendordata HTTP 服务器之间的 keystone 验证方式存在一些担忧。在 Newton 中实现时，如果可用，请求用户的 keystone token 会传递给外部 vendordata 服务器，否则不传递任何 token。
为什么 token 有时不可用？许多元数据操作是由实例在没有关联用户的情况下发起的——例如，cloud-init 在首次启动时调用元数据服务器以确定配置信息。在这种情况下，没有 keystone token 提供给元数据服务。
这种实现存在缺陷，因为 keystone 中间件的工作方式。如果未传递 token 并且 keystone 中间件已启用，则请求将在外部 vendordata 服务器有机会处理请求之前被拒绝。
此外，我们正在验证错误的内容。我们应该确保的是 Nova 元数据服务正在调用外部 vendordata 服务器。为此，我们应该使用 Nova 服务帐户。
为了解决这些问题，我们将改为将 Nova 服务 token 传递给外部 vendordata 服务器。这将是一个专门为此目的创建的新服务 token。此更改被视为一个错误修复，并将回溯到 Newton，以确保外部 vendordata 服务器的实现者具有一致的接口。
来自用户 token 的角色信息¶
我们唯一需要使用用户 token 的地方是角色信息。为了使以后可用（并且不会在用户角色更改时更改），我们将从启动请求中将此信息存储在 Nova 数据库中作为系统元数据，然后将此信息传递给每个请求的外部 vendordata 服务。
在峰会上，认为存储此角色信息很重要，以便元数据请求返回的结果不会随时间变化——例如，如果用户在启动请求时拥有允许他们启动邮件服务器的角色，则该实例应始终保持邮件服务器，无论该用户是否从他们身上删除了该角色。
这不是一个错误修复，将不会回溯。
硬失败模式¶
峰会上的操作员也要求他们希望有一种模式，如果外部 vendordata 服务器未能返回对请求的有效响应，则实例应进入错误状态。这适用于需要从外部服务获取配置信息才能正确运行的用例。
这不是一个错误修复，将不会回溯。
缓存¶
原始规范设想了缓存来自外部 vendordata 服务的响应，但未实现此功能。如果 Ocata 版本允许，我们将添加此支持。
这不是一个错误修复，将不会回溯。
备选方案¶
这项工作是峰会上讨论的后续工作。另一种选择是让新的 vendordata 实现不完整。
数据模型影响¶
没有，除了系统元数据表中存储额外数据外。
REST API 影响¶
无。
安全影响¶
无。
通知影响¶
无。
其他最终用户影响¶
无。
性能影响¶
无。
其他部署者影响¶
部署者需要配置额外的服务 token，才能使用对外部元数据服务的身份验证调用。
开发人员影响¶
无。
实现¶
负责人¶
- 主要负责人
mikalstill
工作项¶
请参阅上述建议的更改。
依赖项¶
无。
测试¶
单元测试
文档影响¶
这些更改对部署者最感兴趣，因此我们应该确保在管理指南中记录它们。
参考资料¶
https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/vendordata-reboot.html
历史¶
这项工作的首次实现是在 Newton 中。
