Pike 系列发布说明

15.0.1

序言

此点版本包含一些小的更改，以确保 Pike 版本的 Glance 与当前的操作系统包保持稳定。

错误修复

• Python 2.7 分发包中的更改影响了 Glance 使用 eventlet 的方式。因此，团队将 eventlet 0.22.0 中的修复移植到 Glance 代码中。（OpenStack Pike 版本使用 eventlet 0.20.0。）有关详细信息，请参阅 Bug 1747304。

15.0.0

序言

• Images API v2 的次要版本号已提升至 2.6，以引入一个 EXPERIMENTAL 版本的 API，其中包含为 Minimal Viable Product 交付重构的镜像导入功能而引入的新调用。版本 2.5 仍然是 Images API 的 CURRENT 版本。

新特性

• Images v2 API 的 image-list 调用现在识别一个 protected 查询字符串参数。此参数仅接受两个值：true 或 false。该过滤器区分大小写。任何其他值都将导致请求收到 400 响应。有关详细信息，请参阅 protected 过滤器规范文档。

• 引入了一个新的策略，tasks_api_access，以便 Glance 可以使用普通用户凭据来管理完成可互操作镜像导入过程的任务，而无需让操作员向最终用户公开 Tasks API。

• Glance 现在包含一个 WSGI 脚本入口点，使其能够作为由高性能 Web 服务器托管的 WSGI 应用程序运行。有关详细信息，请参阅 Glance 文档中的 在 HTTPD 中运行 Glance。

  使用这种方法部署 Glance 存在一些限制，目前我们不建议在生产环境中使用它。有关更多信息，请参阅本文档的 已知问题部分。

已知问题

• 虽然已添加对 Glance 作为 Web 服务器托管的 WSGI 应用程序运行的支持，但 Glance 提供的 Images API 的非典型性质（它能够传输大量的镜像数据）使得这种方法难以在不进行仔细配置的情况下工作。Glance 依赖于分块传输编码进行镜像上传，而 WSGI 规范不需要支持分块传输编码。

  Glance 文档部分 在 HTTPD 中运行 Glance概述了一些使用（和不使用）Glance 与 Apache httpd 服务器的方法。这是 Glance 在 devstack 中配置为 WSGI 应用程序的方式，因此我们对其经验最多。如果您尝试使用不同的 Web 服务器部署 Glance，请考虑将您的发现贡献给 Glance 文档。

  目前，我们在 gate 中配置 Glance 以遵循文档中推荐的指南在 devstack 中运行时遇到了一些问题。您可以关注 Bug 1703856 以了解更多信息。

  据 Glance 团队所知，将 Glance 作为 WSGI 应用程序运行的困难是由 Glance 外部的问题引起的。因此，Glance 团队建议以其正常的独立配置运行 Glance，尤其是在生产环境中。如果您选择在 Web 服务器中将 Glance 作为 WSGI 应用程序运行，请务必使用实际的使用场景仔细测试您的安装。

升级说明

• Glance 提供的 Images API 的一个 EXPERIMENTAL 版本被引入为 2.6。它包含为 重构的镜像导入功能引入的新 API 调用。默认情况下，此功能未启用，因此 Images API 的 CURRENT 版本仍然是 2.5。此版本中没有对版本 2.5 API 的更改，因此所有版本 2.5 调用都将有效，无论是否启用新的导入功能。

  版本 2.6 API 被引入为 EXPERIMENTAL，因为它是在 重构的镜像导入规范中描述的功能的 Minimal Viable Product 交付。作为 MVP，版本 2.6 中的响应在规范中描述的是简化的。预计版本 2.6 将在 Queens 中完成，但目前，我们鼓励操作员尝试新的功能，但请记住其 EXPERIMENTAL 性质。

• 配置选项 store_type_preference 的已弃用值不再被识别。在 Newton 中已弃用的两个非标准值‘filesystem’和‘vmware_datastore’现在不可操作。这些存储的正确值是‘file’和‘vmware’。有关更多信息，请参阅 Newton 发布说明中的 https://docs.openstack.org/releasenotes/glance/newton.html#upgrade-notes。

• OpenStack Artifacts Service (Glare) 的代码及其 EXPERIMENTAL API 已从 Glance 代码库中删除，因为它在之前的发布周期中被迁移到独立的 Glare 项目仓库。Glance Pike 版本的数据库升级将从 Glance 数据库中删除 Glare 表（名为‘artifacts’和‘artifact_*’）。

  在 Newton 和 Ocata 版本期间，提供 Glare 的 OpenStack 部署、打包者和部署项目应该已经开始从其自己的 Glare 仓库中消耗 Glare。在 Pike 版本中，不再可以从 Glance 仓库中消耗 Glare 代码。

• 来自 oslo.concurrency 的 lock_path 配置选项现在是使用 sql image_cache 驱动程序所必需的。如果未指定，它将默认为 image_cache_dir 并发出警告。

• Pike 版本中修改了以下元数据定义

  • 已将属性 img_hide_hypervisor_id 添加到命名空间 OS::Compute::LibvirtImage。

  • 在 OS::Compute::VMware 命名空间中添加了几个 新值，用于属性 vmware_ostype。

  您可以使用以下命令升级这些定义：

  glance-manage db load_metadefs [--path <path>] [--merge] [--prefer_new]

• 您可以在 glance-api.conf 文件中的 keystone_authtoken 组中设置 timeout 选项。

• 如果您希望启用包含新的可互操作镜像导入功能的 EXPERIMENTAL 版本 2.6 API，请将配置选项 enable_image_import 在 glance-api.conf 文件中设置为 True。此选项的默认值为 False。

  可互操作镜像导入功能使用 Glance 任务引擎。这对于最终用户来说是透明的，因为他们不使用 Tasks API 来进行可互操作镜像导入工作流。但是，操作员必须确保以下配置选项设置正确。

  • enable_image_import

  • node_staging_uri

  • [task] 组中的选项

  • [taskflow_executor] 组中的选项

  有关更多信息，请参阅 glance-api.conf 示例文件中的文档。

  此外，您需要验证 Glance policy.json 文件中的与任务相关的策略是否设置正确。这些设置如下所述。

• 引入了一个新的策略，tasks_api_access，以便 Glance 可以使用普通用户凭据来管理完成可互操作镜像导入过程的任务，而无需让操作员向最终用户公开 Tasks API。

  在 Mitaka 中，Tasks API 默认设置为仅限管理员，通过将以下策略目标限制为 role:admin：get_task、get_tasks、add_task 和 modify_task。

  新的 tasks_api_access 策略目标直接控制对 Tasks API 的访问，而刚刚提到的目标间接影响可以通过控制可以对 Glance 内部任务对象执行的操作来通过 API 操作的内容。关键是，如果您希望向最终用户公开新的可互操作镜像导入过程，同时保持 Tasks API 仅限管理员，则可以使用以下设置来实现：

  "get_task": "",
  "get_tasks": "",
  "add_task": "",
  "modify_task": "",
  "tasks_api_access": "role:admin",
  

  总而言之：最终用户不需要访问 Tasks API 才能使用新的可互操作镜像导入过程。但是，他们需要有权访问 Glance 内部任务对象。

  我们建议所有操作员采用刚刚描述的策略设置，而与是否公开 EXPERIMENTAL 版本 2.6 API 无关。

安全问题

• 引入了一个新的策略，tasks_api_access，以便 Glance 可以使用普通用户凭据来管理完成可互操作镜像导入过程的任务，而无需让操作员向最终用户公开 Tasks API。

  现在是时候检查您的 Glance policy.json 文件，以确保如果它包含一个 default 目标，则该规则相当严格（“role:admin”或“!”是好的选择）。当策略引擎找不到它正在查找的目标时，将使用 default 目标。当引入新的策略但使用的策略文件来自先前的版本时，可能会发生这种情况。

错误修复

• Ocata 版本中引入的 实验性零停机数据库升级路径中存在一个错误，该错误阻止了 实验性升级正常工作。此错误已在 Pike 版本中修复。该错误不会影响正常的数据库升级操作。

• 以下是此版本中包含的一些错误修复亮点。

  • Bug 1655727：在 eventlet 0.20.1 足够早的时候调用 monkey_patching

  • Bug 1657459：修复与 WebOb 1.7 的不兼容性

  • Bug 1554412：为 FK 失败提供用户友好的消息

  • Bug 1664709：不要从缓存中提供部分镜像下载请求

  • Bug 1482129：从字典中删除重复的键

  • Bug 1229823：处理镜像缓存中的文件删除竞争

  • Bug 1686488：修复 glance image-download 错误

  • Bug 1516706：防止 v1_api 向 v2_registry 发出请求

  • Bug 1701346：修复 trust auth 机制

• Glance 曾接受 GET v2/images/{image_id}/file 请求的 Content-Range 标头，这与 RFC 7233 相反。遵循 RFC 7233，Glance 现在将

  • 接受 Range 标头以请求提供部分镜像。

  • 在成功交付请求的部分内容后，包含 Content-Range 标头。

  请注意，并非所有 Glance 存储后端都支持部分下载。向具有此类后端的 Glance 服务器发送 Range 请求将导致交付整个镜像内容，尽管响应代码为 206。

• 请注意 Scrubber 在作业获取错误情况下的行为变化

  • 如果配置为以守护程序模式工作，Scrubber 将记录级别为 critical 的错误消息，但不会退出进程。

  • 如果配置为以非守护程序模式工作，Scrubber 将记录级别为 critical 的错误消息并以状态 1 退出。

其他说明

• OpenStack Artifacts Service (Glare) 的代码及其 EXPERIMENTAL API 已从 Glance 代码库中 删除。

  Artifacts API 是在 Liberty 版本中作为 /v3 在 Glance 服务端点上运行的 EXPERIMENTAL API。在 Mitaka 版本中，Glance /v3 EXPERIMENTAL API 已被弃用，Artifacts Service 在其自己的端点上运行（完全独立于 Glance 服务端点）作为 EXPERIMENTAL API，版本为 v0.1。在 Liberty 和 Mitaka 版本中，Glare 运行在 Glance 代码仓库中的代码，并使用 Glance 数据库中的自己的表。

  在 Newton 版本中，Glare 代码被迁移到其自己的 Glare 项目仓库。在 Newton 版本中，Glare 运行一个 EXPERIMENTAL Artifacts API，版本为 v1.0，在其自己的端点上，并使用其自己的数据库。

  对于 Pike 版本，遗留的 Glare 代码已从 Glance 代码仓库中删除，遗留的‘artifacts’和‘artifact_*’数据库表已从 Glance 数据库中删除。由于 Artifacts 服务 API 在 Glance 中是一个 EXPERIMENTAL API，并且自 Mitaka 以来未在 Glance 数据库中使用，因此未提供从 Glance 数据库迁移到 Glare 数据库的机制。

• 根据新的 OpenStack 项目标准布局，文档已重新组织。

• Glance 现在使用 python ‘cryptography’ 模块，而不是 ‘pycrypto’ 模块。

• 根据当前的 OpenStack 策略，Glance 日志消息不再被 翻译。

• Image Service API 参考已更新，其中包含有关 可互操作镜像导入过程（也称为“重构的镜像导入”）以及暴露于 API v2 的 EXPERIMENTAL 版本的 API 调用的部分。