Ocata 系列发布说明

14.0.1

序言

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

错误修复

• Python 2.7 分发包中的更改影响了 Glance 使用 eventlet 的方式。因此，团队将 eventlet 0.22.0 中的修复程序回溯到 Glance 代码中。（OpenStack 的 Ocata 版本使用 eventlet 0.19.0。）有关详细信息，请参阅 Bug 1747305。

其他说明

• 已更新翻译。

14.0.0

序言

• 将 ploop 添加到支持的磁盘格式列表中。

• 实验性零停机数据库升级，使用一系列扩展-迁移-收缩操作，可用。

• Images API v2 的次要版本升级到 2.5。

• 在 Images API v2 中引入了社区镜像功能。这使用户能够将镜像供其他所有用户使用。与此更改相关联的是，镜像的“可见性”值已扩展为包括“community”（社区）和“shared”（共享）。

现在，镜像的位置更新仅限于状态为 active（活动）或 queued（排队）的镜像。有关更多信息，请参阅“Bug 修复”部分。

新特性

• 已将 ploop 标识符添加到 Glance 中支持的磁盘格式列表中。相应的配置选项已更新，默认列表显示 ploop 作为受支持的格式。

• 镜像“可见性”更改。

  • 在 Ocata 之前，具有“private”（私有）可见性的镜像可以通过向其添加成员来共享，尽管其可见性仍然是“private”。为了使镜像的可见性更加清晰，Ocata 中引入了以下更改

    • 引入了可见性的新值“shared”（共享）。具有或可以接受成员的镜像将不再显示为具有“private”可见性，从而减少了最终用户的困惑。

    • 镜像必须具有“shared”可见性才能接受成员。这可以防止“private”镜像被无意中共享。

    • 为了保留与当前共享工作流程的向后兼容性，Ocata 中镜像的默认可见性为“shared”。与 Ocata 之前的行为一致，这将允许镜像在无需先更新镜像的可见性的情况下接受成员操作。（请记住，具有“shared”可见性但没有成员的镜像实际上无法供镜像所有者以外的任何人访问，因此本身不是安全问题。）

• 可以在创建镜像时指定镜像可见性。

  • 如上所述，镜像的默认可见性为“shared”。如果用户希望镜像为私有且不接受任何成员，则可以在创建时显式分配“private”可见性。

    • 这样的镜像需要将其可见性更新为“shared”才能接受成员。

• 使用镜像更新（PATCH）调用更改镜像可见性。

  • 注意：这不是一个更改。只是为了完整性而提及。

• 引入了镜像“visibility”（可见性）字段的新值“community”（社区）。

  • 具有“community”可见性的镜像可供任何用户使用。

  • 为了防止用户向其他用户的镜像列表响应发送垃圾邮件，除非用户明确请求，否则社区镜像不会包含在镜像列表响应中。

    • 例如，GET v2/images?visibility=community

    • 与镜像列表调用标准行为一样，可以对请求应用其他过滤器。例如，要查看用户 931efe8a-0ad7-4610-9116-c199f8807cda 提供的社区镜像，将发出以下调用：GET v2/images?visibility=community&owner=931efe8a-0ad7-4610-9116-c199f8807cda

升级说明

• 配置选项 disk_format 默认启用 ploop 支持。

• 在本版本中，Glance 用于数据库升级的数据库迁移引擎已从SQLAlchemy Migrate 更改为Alembic。

  • 这导致迁移脚本的位置和命名约定发生变化。强烈建议开发人员、操作员和 DevOps 仔细阅读 Glance 文档的 数据库管理 部分，了解 Ocata 版本中引入的更改的详细信息。以下是更改的简要摘要

    • 所有 glance manage db 命令都已相应更改，以使用 Alembic 执行诸如 version（版本）、upgrade（升级）、sync（同步）和 version_control（版本控制）等操作。因此，“旧式”迁移脚本将不再适用于 Ocata glance manage db 命令。

    • 数据库版本不再是数字。相反，它们是应用于数据库的最后一个迁移的修订 ID。

      • 例如，Liberty 迁移，在旧系统中版本为 42，现在将显示为 liberty。Mitaka 迁移 43 和 44 分别显示为 mitaka01 和 mitaka02。

  • 进行迁移引擎更改是为了实现零停机数据库升级，这是 Glance 滚动升级工作的一部分（计划在 Pike 版本中实现）。

    • 本版本提供零停机数据库升级的预览，但它是实验性的并且不适用于生产系统。有关详细信息，请参阅 Glance 文档的 数据库管理 部分。

• Glance 提供的版本 2 Images API 的CURRENT（当前）版本现在是 2.5。更改包括

  • “visibility”（可见性）枚举已从两个值（public（公共）、private（私有））增加到四个值（public（公共）、private（私有）、shared（共享）和 community（社区））。

  • 以前，可以向可见性为 private 的镜像添加成员，从而创建一个“shared”镜像。在本版本中，镜像必须具有“shared”可见性才能接受成员操作。尝试向可见性为 private 的镜像添加成员将导致 4xx 响应，其中包含信息性消息。

• 一些后端存储名称在 glance 和 glance_store 之间不一致。这意味着使用 VMware 数据存储或文件系统存储的操作员需要使用在 glance_store 中没有有效标识符的存储名称在 glance-api.conf 中使用。由于这种情况会鼓励错误配置和操作员的不满，因此我们在 Newton 版本中使存储名称保持一致。这对您意味着什么

  • 此更改仅适用于使用多个镜像位置的操作员

  • 此更改仅适用于使用 VMware 数据存储或文件系统存储的操作员

  • 此更改仅适用于 store_type_preference 选项

  • VMware 数据存储操作员：旧名称，现在已DEPRECATED（已弃用），为 vmware_datastore。新名称，在 glance 和 glance_store 中使用，为 vmware

  • 文件系统存储操作员：旧名称，现在已DEPRECATED（已弃用），为 filesystem。新名称，在 glance 和 glance_store 中使用，为 file

  • 此更改是向后兼容的，也就是说，在弃用期间代码将识别旧名称。对已弃用名称的支持将在 Pike 版本中删除

  • 我们强烈建议操作员立即修改他们的 glance-api.conf 文件以使用新名称

• 引入了镜像“visibility”（可见性）字段的新值“community”（社区）。

  • 更新镜像为“community”可见性由名为“communitize_image”的策略目标控制。默认情况下为空，也就是说，任何用户都可以使镜像成为社区镜像。

• 当前镜像的可见性迁移

  • 在 Ocata 之前，Glance 数据库没有“visibility”（可见性）列，而是使用了一个布尔值“is_public”（是否公开）列，该列在 Images API v2 镜像响应中转换为“public”（公共）或“private”（私有）可见性。作为升级到 Ocata 的一部分，在 images 表中引入了一个“visibility”列。它将按如下方式填充

    • 当前具有“public”可见性的所有镜像（即数据库中“is_public”为 True 的镜像）其可见性将被设置为“public”。

    • 当前具有“private”可见性的镜像（即数据库中“is_public”为 False 的镜像）并且具有镜像成员的镜像，其可见性将被设置为“shared”。

    • 当前具有“private”可见性的镜像（即数据库中“is_public”为 False 的镜像）并且没有镜像成员的镜像，其可见性将被设置为“private”。

      • 请注意，这样的镜像必须将其可见性更新为“shared”才能接受成员。

• Ocata 可见性更改对 Images API v2 的最终用户的影响

  • 我们试图最大限度地减少对最终用户的影响，但想指出一些需要注意的问题。

    • 镜像可见性的迁移为镜像分配了有意义的值，即为最终用户未分配成员的镜像分配“private”，为升级时具有成员的镜像分配“shared”。以前，如果最终用户想要共享私有镜像，可以直接添加成员。升级后，必须先将镜像的可见性更改为“shared”，然后才能添加成员。

    • “shared”的默认值可能看起来很奇怪，但它保留了升级前的流程：(1) 使用默认可见性创建镜像，(2) 向该镜像添加成员。此外，具有“shared”可见性但没有成员的镜像无法供其他用户访问，因此在功能上是私有镜像。

    • 镜像创建操作允许在创建镜像时设置可见性。鉴于之前只有两个可见性值可用，其中一个（“public”）默认情况下无法由最终用户分配，因此此选项可能没有被广泛使用。操作员可能希望更新其文档或工具，以便在最终用户创建镜像时指定可见性值。总而言之

      • “public”（公共）- 默认保留给操作员提供的所有用户使用的镜像

      • “private”（私有）- 镜像仅可供其所有者访问

      • “community”（社区）- 镜像可供所有用户使用

      • “shared”（共享）- 镜像完全可供所有者访问，并且可供任何镜像成员使用

• Ocata 可见性更改对 Images API v1 的影响

  • 已弃用的 Images API v1 没有“visibility”（可见性）的概念，并且在“纯”v1 部署中，您不会注意到任何更改。但是，由于我们希望不再有太多这样的部署，因此以下是您在“混合”部署中使用 Images API v1 时可能会看到的情况。

    • 在 v1 API 中，镜像有一个 is_public 字段（但没有 visibility 字段）。is_public 为 True 的镜像等效于 v2 API 中具有“public”可见性的镜像。is_public 为 false 的镜像等效于 v2 API 中具有“shared”可见性的镜像（如果它们有成员），或者等效于 v2 API 中具有“private”可见性的镜像（如果它们没有成员）。

    • 在 v2 API 中具有“community”可见性的镜像在 v1 API 中将具有 is_public == False。它将表现为私有镜像，也就是说，只有所有者（或管理员）才能访问该镜像，并且只有所有者（或管理员）才能在镜像列表中看到该镜像。

    • 由于镜像创建的默认值为“shared”，因此使用 v1 API 刚刚创建的镜像可以添加成员，就像在 Ocata 之前一样。

    • 如果镜像在 v2 API 中具有“private”可见性，则该镜像在 v1 API 中将无法接受成员。如果用户想要共享这样的镜像，用户可以

      • 使用 v2 API 将镜像的可见性更改为“shared”。然后，它将在 v1 或 v2 API 中接受成员。

      • 使用 v1 API 更新镜像，使 is_public 为 False。这将重置镜像的可见性为“shared”，现在它可以接受成员操作。

      • 请注意，在任何一种情况下，当处理在 v2 API 中具有“private”可见性的镜像时，都有一个保障措施，可以防止用户无意中向镜像添加成员并公开数据。该保障措施是，您必须在 v1 或 v2 API 中执行额外的镜像更新操作，然后才能将其暴露给其他用户。

• oslo.log 的一项最新更改（>= 3.17.0）将 [DEFAULT]/use_stderr 的默认值设置为 False，以防止日志重复（如 bug #1588051 中报告的那样）。由于这将更改某些 Glance 命令的当前行为（例如，glance-replicator、glance-cache-manage 等），我们选择在这些命令中将 use_stderr 的默认值覆盖为 True。我们还选择不在任何 Glance 服务（例如，glance-api、glance-registry）中覆盖该值，以免这些服务创建重复的日志。如果操作员有依赖于将日志报告到标准错误的用例，可以在部署时在适当服务的配置文件中设置 [DEFAULT]/use_stderr = True。

• 针对 OS::Compute::Hypervisor 命名空间中 hypervisor_type 的元数据定义已扩展，包含 Virtuozzo hypervisor，指定为 vz。您可以使用以下命令升级定义：

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

安全问题

• 所有 qemu-img info 调用现在都在资源限制下运行，这些限制将运行该命令的进程的 CPU 时间和地址空间使用量分别限制为 2 秒和 1 GB。 这解决了 bug https://bugs.launchpad.net/glance/+bug/1449062。 目前“qemu-img”的使用仅限于 Glance 任务，这些任务默认情况下（自 Mitaka 版本发布以来）仅对管理员用户可用。 我们继续建议仅将任务暴露给受信任的用户

错误修复

• 对状态不是 active 或 queued 的镜像更新镜像位置可能会引入竞争条件和安全问题，从而给用户和操作员带来糟糕的体验。因此，我们在此版本中限制了镜像位置更新。用户现在会观察到以下情况：

  • 当镜像状态不是 active 时，尝试删除镜像位置将返回 HTTP 响应代码 409 (Conflict)

  • 当镜像状态不是 active 或 queued 时，尝试替换镜像位置将返回 HTTP 响应代码 409 (Conflict)

其他说明

• 由于 OSSN-0065 的缓解说明引用了此选项，因此配置选项 show_multiple_locations 的弃用路径已更改。现在它将在 Pike 版本或之后被移除。此选项的帮助文本已相应更新。