Monasca Events Publishing - 来自 Ceilometer

https://storyboard.openstack.org/#!/story/2003023

Monasca Events API [1] 旨在将 Openstack 通知数据存储在 Elasticsearch 中。仍然需要收集和发布 Openstack 通知到 Monasca Events API。Monasca Ceilometer 项目[2] 目前发布 ceilometer 样本[3] 到 Monasca API。我们建议扩展 Monasca Ceilometer 项目，并添加一个新的事件发布器，它将发布 Openstack 通知（或事件）[3] 到 Monasca Events API。

更新：此规范正在被 ../../stein/approved/monasca-events-listener.rst 规范取代，但此处保留以供参考。

问题描述

所有 Openstack 服务都会生成大量的通知或事件，其中包含大量关于服务及其资源的操作和状态信息。这些通知数据目前在 Monasca 中不可用。

Ceilometer 数据处理管道[3] 提供了一种可扩展的机制，可以使用自定义发布器发布样本和事件。Ceilometer 样本代表可以被测量的一个量（例如，卷的大小），而事件代表一个事件的发生，没有相关的量（例如，创建了卷）。

Monasca Ceilometer 项目目前提供一个样本发布器。Monasca Ceilometer 样本发布器将 Ceilometer 样本转换为 Monasca Metrics 格式，然后发布到 Monasca API。目前还没有相应的事件发布器到 Monasca。

通过向 Monasca Ceilometer 项目添加一个事件发布器，我们可以利用 Ceilometer 的事件发布机制将事件发布到 Monasca Events API。

Ceilometer 由不同的数据收集组件组成 - 即轮询 Agent、通知 Agent 和 Compute Agent。（请参阅 [7] 获取系统架构图）Ceilometer 还具有数据存储和检索组件，在我们的例子中将是 Monasca。

样本发布器和新提出的事件发布器都在 Ceilometer 的通知 Agent 组件内运行，并且是通知 Agent 数据处理管道的一部分。Monasca Ceilometer 假定需要在所有控制节点上安装和部署 Ceilometer 通知 Agent 组件（不需要部署轮询 Agent 或 Compute Agent）。Ceilometer 通知 Agent 是高可用 (HA) 的，可以在多个节点上运行。我们需要评估其在事件扩展方面的性能，但我们尚未在当前的样本发布器中遇到性能/扩展问题。

用例

  1. Openstack 通知数据将通过 Monasca Events API 存储在 Elasticsearch 中

    从 Nova 通知到 Monasca API 的示例序列 #。Nova 完成了 VM 的创建 #。Nova 生成一个通知消息到 oslo.messaging #。Ceilometer 通知 Agent 接收通知消息 #。Ceilometer 将通知转换为 Monasca API 格式，根据配置 #。Ceilometer 事件发布器将格式化的通知发布到 Monasca Events API #。Monasca Events API 接收并验证格式化的通知 #。Monasca Events 将事件通知存储在配置的 Elasticsearch 实例中

提议的变更

  1. Openstack 通知由 envelope 和 payload 字段组成

    Openstack 通知数据格式示例

    {
    "_context_auth_token": "42630b3ea13242fcad20e0a92d0207f1",
    "_context_domain": null,
    "_context_instance_lock_checked": false,
    "_context_is_admin": true,
    "_context_project_domain": null,
    "_context_project_id": "a4f77",
    "_context_project_name": "admin",
    "_context_quota_class": null,
    "_context_read_deleted": "no",
    "_context_read_only": false,
    "_context_remote_address": "192.168.245.4",
    "_context_request_id": "req-5948338c-f223-4fd8-9249-8769f7a3e460",
    "_context_resource_uuid": null,
    "_context_roles": [
        "monasca-user",
        "admin",
        "KeystoneAdmin"
    ],
    "_context_service_catalog": [
        {
            "endpoints": [
                {
                    "adminURL": "http://192.168.245.8:8776/v2/a4f77",
                    "internalURL": "http://192.168.245.8:8776/v2/a4f77",
                    "publicURL": "http://192.168.245.9:8776/v2/a4f77",
                    "region": "region1"
                }
            ],
            "name": "cinderv2",
            "type": "volumev2"
        },
        {
            "endpoints": [
                {
                    "adminURL": "http://192.168.245.8:8776/v1/a4f77",
                    "internalURL": "http://192.168.245.8:8776/v1/a4f77",
                    "publicURL": "http://192.168.245.9:8776/v1/a4f77",
                    "region": "region1"
                }
            ],
            "name": "cinder",
            "type": "volume"
        }
    ],
    "_context_show_deleted": false,
    "_context_tenant": "a4f77",
    "_context_timestamp": "2015-09-18T20:54:23.468522",
    "_context_user": "be396488c7034811a200a3cb1d103a28",
    "_context_user_domain": null,
    "_context_user_id": "be396488c7034811a200a3cb1d103a28",
    "_context_user_identity": "be396488c7034811a200a3cb1d103a28 a4f77 - - -",
    "_context_user_name": "admin",
    "_unique_id": "ff9699d587bf4283a3c367ab88be1541",
    "event_type": "compute.instance.create.start",
    "message_id": "c6149ba1-34b3-4367-b8c2-b1d6f073742d",
    "payload": {
        "access_ip_v4": null,
        "access_ip_v6": null,
        "architecture": null,
        "availability_zone": null,
        "cell_name": "",
        "created_at": "2015-09-18 20:55:25+00:00",
        "deleted_at": "",
        "disk_gb": 1,
        "display_name": "testeee",
        "ephemeral_gb": 0,
        "host": null,
        "hostname": "testeee",
        "image_meta": {
            "base_image_ref": "df0c8",
            "container_format": "bare",
            "disk_format": "qcow2",
            "min_disk": "1",
            "min_ram": "0"
        },
        "image_name": "glanceaaa3",
        "image_ref_url": "http://192.168.245.5:9292/images/df0c8",
        "instance_flavor_id": "1",
        "instance_id": "abd2ef5c-0381-434a-8efc-d7b39b28a2b6",
        "instance_type": "m1.tiny",
        "instance_type_id": 4,
        "kernel_id": "",
        "launched_at": "",
        "memory_mb": 512,
        "metadata": {},
        "node": null,
        "os_type": null,
        "progress": "",
        "ramdisk_id": "",
        "reservation_id": "r-1ghilddw",
        "root_gb": 1,
        "state": "building",
        "state_description": "",
        "tenant_id": "a4f77",
        "terminated_at": "",
        "user_id": "be396488c7034811a200a3cb1d103a28",
        "vcpus": 1
    },
    "priority": "INFO",
    "publisher_id": "compute.ccp-compute0001-mgmt",
    "timestamp": "2015-09-18 20:55:37.639023"
}

  2. 所有以 ‘_context” 开头字段都是 envelope 字段，其他有趣的字段是

    1. ‘message_id’ - 通知标识符

    2. ‘payload’ - 包含 JSON 格式的大部分相关和有用信息

    3. ‘priority’ - 通知优先级

    4. ‘publisher_id’ - 通知发布者

    5. ‘timestamp’ - 通知时间戳

  3. Ceilometer 事件发布框架将 Openstack 通知转换为事件格式[4]。事件发布框架还能够仅提取 ‘payload’ 数据中的一部分到一组扁平化的键值对中，称为 ‘traits’，并使用自定义发布器发布提取了 ‘payload’ 的标准化 ‘event’。

    从 payload 中提取某些字段到 traits 由配置文件驱动，但默认情况下，“publisher_id”、‘request_id’、‘tenant_id’、‘user_id’ 和 ‘project_id’ 字段始终被提取并作为 ‘traits’ 添加。

    如果 ceilometer.conf 中设置了 ‘store_raw’ 选项，则该事件还可以有一个可选字段，称为 ‘raw’，其中包含原始通知。

    问题/TODO

    • Q1：store_raw 字段是否仅适用于事件，还是适用于 Ceilometer 处理的所有通知？

    • 我们需要找出它是否对样本发布器有任何不利影响。尽管在样本的情况下，monasca 样本发布器肯定不会提交原始 payload，所以它肯定会被丢弃。

    Ceilometer 事件数据格式示例

    {
  "event_type": "compute.instance.create.start",
  "message_id": "c6149ba1-34b3-4367-b8c2-b1d6f073742d",
  "generated": "2015-09-18 20:55:37.639023",
  "traits": {
     "publisher_id": "compute.ccp-compute0001-mgmt",
     "request_id": "req-5948338c-f223-4fd8-9249-8769f7a3e460",
     "tenant_id": "a4f77",
     "project_id": "a4f77",
     "user_id": "be396488c7034811a200a3cb1d103a28"
   },
   "raw": {  "_context_auth_token": "42630b3ea13242fcad20e0a92d0207f1",
             "_context_domain": null,
             ...
             ...
             "event_type": "compute.instance.create.start",
             "message_id": "c6149ba1-34b3-4367-b8c2-b1d6f073742d",
             "payload": {
                 "access_ip_v4": null,
                 "access_ip_v6": null,
                 "architecture": null,
                 "availability_zone": null,
                 "cell_name": "",
                 "created_at": "2015-09-18 20:55:25+00:00",
                 "deleted_at": "",
                 "disk_gb": 1,
                 "display_name": "testeee",
                 "ephemeral_gb": 0,
                 "host": null,
                 "hostname": "testeee",
                 "image_meta": {
                     "base_image_ref": "df0c8",
                     "container_format": "bare",
                     "disk_format": "qcow2",
                     "min_disk": "1",
                     "min_ram": "0"
                 },
                "image_name": "glanceaaa3",
                "image_ref_url": "http://192.168.245.5:9292/images/df0c8",
                "instance_flavor_id": "1",
                "instance_id": "abd2ef5c-0381-434a-8efc-d7b39b28a2b6",
                "instance_type": "m1.tiny",
                "instance_type_id": 4,
                "kernel_id": "",
                "launched_at": "",
                "memory_mb": 512,
                "metadata": {},
                "node": null,
                "os_type": null,
                "progress": "",
                "ramdisk_id": "",
                "reservation_id": "r-1ghilddw",
                "root_gb": 1,
                "state": "building",
                "state_description": "",
                "tenant_id": "a4f77",
                "terminated_at": "",
                "user_id": "be396488c7034811a200a3cb1d103a28",
                "vcpus": 1
                }
          }
}

  4. 可以从 ‘payload’ 中提取的键值对可以以 traits 的形式定义在事件定义文件中。

    例如，以下事件定义 yaml 指定对于所有以 “compute.instance.*” 开头的事件，则从 “payload.user_id”、“payload.instance_id” 和 “payload.instance_type_id” 分别提取值后，添加 “user_id”、“instance_id” 和 “instance_type_id” 作为 traits。

    — - event_type: compute.instance.*

    traits: &instance_traits
    user_id

    fields: payload.user_id

    instance_id

    fields: payload.instance_id

    instance_type_id

    type: int fields: payload.instance_type_id

    我们现在建议不使用此功能，为每个事件提取定义 traits，因为我们有能力通过 Monasca Events API 存储整个 payload。

    如果我们在存储整个 JSON “payload” 到 Elasticsearch 中遇到麻烦，我们当然可以在将来考虑启用此功能。这绝对是一种修剪将要存储的数据量的好方法。

  5. 新提出的 Monasca Ceilometer 事件发布器将在 Ceilometer 的通知 Agent 组件内运行。它将利用 Ceilometer 的数据处理管道[3]，将通知转换为 Ceilometer 的事件格式。在其处理结束时，Monasca Ceilometer 事件发布器会将 Ceilometer 事件数据转换为 Monasca 事件格式[6]，并将 monasca 事件发布到 Monasca Events API。

  6. Monasca Events API 允许一个名为 ‘payload’ 的字段，该字段可以是任意嵌套的 JSON 格式。Monasca-Ceilometer 事件发布器将从 ‘raw’（JSON 路径表示法：‘raw.payload’）中提取名为 ‘payload’ 的 JSON 字段，并将来自原始通知的 payload 发布到 Monasca Events API。

    Monasca 事件格式示例

    events: [
{
  dimensions": {
        "service": "compute.ccp-compute0001-mgmt",
        "topic": "notification.sample",
        "hostname": "nova-compute:compute
  },
  event: {

          "event_type": "compute.instance.create.start",

          "payload": {
               "access_ip_v4": null,
               "access_ip_v6": null,
               "architecture": null,
               "availability_zone": null,
               "cell_name": "",
               "created_at": "2015-09-18 20:55:25+00:00",
               "deleted_at": "",
               "disk_gb": 1,
               "display_name": "testeee",
               "ephemeral_gb": 0,
               "host": null,
               "hostname": "testeee",
               "image_meta": {
                   "base_image_ref": "df0c8",
                   "container_format": "bare",
                   "disk_format": "qcow2",
                   "min_disk": "1",
                   "min_ram": "0"
               },
              "image_name": "glanceaaa3",
              "image_ref_url": "http://192.168.245.5:9292/images/df0c8",
              "instance_flavor_id": "1",
              "instance_id": "abd2ef5c-0381-434a-8efc-d7b39b28a2b6",
              "instance_type": "m1.tiny",
              "instance_type_id": 4,
              "kernel_id": "",
              "launched_at": "",
              "memory_mb": 512,
              "metadata": {},
              "node": null,
              "os_type": null,
              "progress": "",
              "ramdisk_id": "",
              "reservation_id": "r-1ghilddw",
              "root_gb": 1,
              "state": "building",
              "state_description": "",
              "tenant_id": "a4f77",
              "terminated_at": "",
              "user_id": "be396488c7034811a200a3cb1d103a28",
              "vcpus": 1
              }
         },
    publisher_id: "compute.ccp-compute0001-mgmt",
    priority: "INFO"
 }
]

  7. 如果在事件管道 yaml 配置文件中未指定 traits，则 Ceilometer 的数据处理管道将添加以下默认 traits

    • service：（所有通知都应该有此项）通知的发布者

    • tenant_id

    • request_id

    • project_id

    • user_id

    注意：“service” 不是生成事件的服务，例如 “compute”、“glance”、“cinder”，而是生成事件的通知 RabbitMQ 发布者，例如 “compute.ccp-compute0001-mgmt”，因此不是很有用。

  8. Ceilometer 事件数据在发布到 Monasca Event API 之前被转换为 Monasca 事件数据格式。以下字段在 Monasca Event 数据中不可用，在当前的 Ceilometer 事件数据格式中

    • “service”

    • “dimensions.topic”

    • “event.priority”

    我们建议从 Monasca Event 格式中删除这些字段（将在单独的规范/实现过程中完成），原因如下

    “service”：目前 Openstack 通知没有以一致的方式指定生成通知的服务。有可能创建一个外部映射文件，将事件名称映射到服务，但很难在一段时间内维护这样的映射。

    “dimensions.topic”：此字段在源 Openstack 通知中不可用

    “event.priority”：此字段当前在 Ceilometer 事件格式中不可用。它在源 Openstack 通知中可用。注意：如果我们认为此字段有用，我们可以建议将其添加到 Ceilometer 事件格式。

  9. 以下新字段将作为维度添加到 Monasca Event 数据中

    • “dimensions.publisher_id”：生成事件的发布者的标识符。映射到 Ceilometer 事件数据中的 “traits.publisher_id”。

    • “dimensions.user_id”：生成事件的用户的标识符。映射到 Ceilometer 事件数据中的 “traits.user_id”。

    • “dimensions.project_id”：生成事件的项目标识符。映射到 Ceilometer 事件数据中的 “traits.project_id” 或 “traits.tenant_id”。

  10. hostname 在事件 payload 中可用，但其位置可能因事件而异。我们可以使用 Ceilometer 的事件定义配置始终将名为 “hostname” 的 trait 添加到所有事件。例如，对于 compute.instance.* 将有一个名为 “hostname” 的 trait，它从 “payload.hostname” 提取数据

    — - event_type: compute.instance.*

    traits: &instance_traits
    user_id

    fields: payload.hostname

  11. 新提出的 Monasca Ceilometer 事件发布器将能够以批处理方式提交事件数据，并以可配置的频率（类似于当前的样本发布器）。如果当前批处理中的项目达到其最大大小（配置设置），或者自上次发布以来经过了某个时间间隔（配置设置），则将发布事件数据。这将确保批处理不会变得巨大，同时也不会对将事件发布到 Monasca Events API 造成重大延迟。

  12. Monasca Ceilometer 事件发布器将使用 ceilometer 配置文件（在“[monasca]”部分中）中的服务凭据来获取 keystone token。

    ceilometer 配置文件中的示例“[monasca]”部分 .. code-block:: text

    [monasca] service_auth_url = https://:5000/v3 service_password = secretpassword service_username = ceilometer service_interface = internalURL service_auth_type = password # service_project_id 也可用 service_project_name = admin service_domain_name = Default service_region_name = RegionOne

    发布器然后将向 Monasca Events /v1.0/events REST api[8] 发送 POST 请求，以将事件发布到 Monasca Events API。Monasca Events API 的实例的 URL 将在 Ceilometer ‘events-pipeline.yaml’ 文件中配置。这具有添加优势，允许以不同的方式发布不同的事件（请参阅 Ceilometer 管道文档 [10]）。

  13. 与通知相关的 “tenant_id” 和 “user_id” 在通知的 “payload” 部分中可用，并且这些通知由每个服务本身生成。

    没有额外的 “Openstack-operator-agent” 类型的组件或功能需要从服务中获取该数据并代表原始租户发布到 monasca event api。Ceilometer 发布管道只是从 “payload” 中提取这些 “tenant_id” 和 “user_id” 字段，并将这些字段作为 “tenant_id” 和 “user_id” traits 提供，然后这些 traits 将被映射到 monasca events 格式中的 “dimensions.project_id” 和 “dimensions.user_id” 字段。

    换句话说，原始 “tenant_id” 和 “user_id” 值在通知的 payload 中可用，并将进入 Monasca Event 中的 “dimensions.tenant_id” 和 “dimensions.user_id”。

    问题/TODO：* Q：是否需要在 monasca-events api 中执行类似于 metrics[9] 中所做的那样处理多租户？原始的 “dimensions.user_id” 和 “dimensions.tenant_id” 字段中的 “user_id” 和 “tenant_id” 是否能达到此目的？ * Q：在 Ceilometer V2 API（已弃用并删除）中，查询数据时，具有 “admin” 角色的用户可以访问所有租户的数据，而具有 “ceilometer-admin” 角色的用户只能访问特定租户的数据。我们是否可以为 monasca-events api 查询数据实现类似的功能？

  14. Monasca Ceilometer 事件发布器还将重试提交批处理，以防 Monasca Events API 暂时不可用或关闭。重试频率、重试次数以及重试批处理中可以包含的项目数也将通过配置设置。

替代方案

  1. 独立的 monasca 事件 Agent，它读取发布到 RabbitMQ（在“notification”主题上）的 Openstack 通知，并将它们发布到 Monasca Events API。优点：* 无需依赖 Telemetry 项目。 * 如果利用 oslo.messaging 功能，开发起来可能很简单。 * Ceilometer 在 Stein 版本中已弃用事件功能。[13] 缺点：* 另一个 Agent 需要说服用户安装到他们的系统上。 * 重新发明已经在 Ceilometer Agent 中完成的工作。OpenStack 社区已经使用 Ceilometer 并贡献更新，当出现问题时。这种替代方案将在单独的规范中详细说明，因为它可能是 Monasca 长期需要的解决方案。

  2. Openstack Panko [5] 是 Ceilometer 的事件存储和 REST API。优点：* 是 Telemetry 中的一个“官方”子项目，因此具有一些社区认可。缺点：* 其主要存储在关系数据库中，这存在扩展问题。 * 它没有积极维护，并且尚未准备好投入生产。[11] * 它最终将被弃用。[12]

数据模型影响

无

REST API 影响

  1. 我们建议通过删除和添加“Proposed change”部分中提到的以下字段来调整 Monasca Event 数据格式。

    删除字段（JSON 路径表示法）：“service”、“dimensions.topic”、“dimensions.hostname” 和 “event.priority”

    添加字段（JSON 路径表示法）：“dimensions.publisher_id”、“dimensions.user_id” 和 “dimensions.project_id”

    此更改将对 Monasca Events API 产生影响。

安全影响

拟议的 Monasca Ceilometer 事件发布器将收集并发布 Openstack 事件（通知）数据到 Monasca API。Openstack 通知数据没有像 ‘tokens’ 这样的任何敏感数据。通知包含 ‘user_id’ 和 ‘project_id’ 字段，但不包含用户或项目的任何个人身份信息 (PII)。

其他最终用户影响

无。

性能影响

  1. 不同服务生成的通知（事件）数量将取决于云的容量以及用户创建的资源数量。

    例如，如果创建或销毁了大量的计算虚拟机，可能会导致通知（事件）数量激增，这些通知需要被发布。需要记录与事件批量大小和事件批量间隔等相关的最佳配置选项，以减少对性能的任何不利影响。

  2. Monasca Ceilometer 发布者在 Ceilometer 通知代理组件内运行，并作为其数据处理管道的最后一步被调用。它是一个额外的组件，必须部署到所有控制器节点上。我们需要评估 Ceilometer 通知代理在将事件发布到 Monasca Events API 时的性能影响。

其他部署者影响

  1. 提议的新 Monasca-Ceilometer 事件发布者将引入一些新的配置选项，例如：* 事件 API 端点 * 事件批量间隔 * 事件批量大小 * 事件重试间隔

  2. Monasca Ceilometer 事件发布者必须添加到 Ceilometer 的“[ceilometer.event.publisher]”部分 entry_points.txt 文件中

    例如

    [ceilometer.event.publisher] monasca = ceilometer.publisher.monclient:MonascaEventsPublisher

  3. 作为开发新的 Monasca Ceilometer 事件发布者的一部分，devstack 插件将被更新以添加上述配置更改。

开发者影响

  1. 对 Monasca Event Format 的提议更改将对现有的 Monasca Event API 产生影响，因为 Monasca Event Format 需要进行调整。（请参阅上文的 REST API Impact 部分）

实现

负责人

主要负责人

joadavis, aagate

其他贡献者

<launchpad-id 或 None>

工作项

  1. 实现新的 Monasca Ceilometer 事件发布者。

  2. 实现 monasca-ceilometer devstack 插件更改以部署新的事件发布者。

  3. 为事件发布者实现单元测试。

  4. 在 Monasca Events API 中实现对 Monasca Event 格式的更改。

依赖项

  1. Monasca Events API 1.0: https://storyboard.openstack.org/#!/story/2001654

  2. Monasca Ceilometer 项目: https://github.com/openstack/monasca-ceilometer

#. Ceilometer 数据处理和管道: https://docs.openstack.org/ceilometer/pike/admin/telemetry-data-pipelines.html

测试

  1. 新的 Monasca Ceilometer 事件发布者单元测试将被添加，可以测试使用各种配置选项事件批量大小、事件批量间隔、处理 Monasca Event API 不可用时的重试。

  2. 可以考虑将 Monasca Ceilometer 事件发布者的 tempest 测试作为单独的工作来完成。

    请注意，当前的 Monasca Ceilometer 样本发布者也没有 tempest 测试，因此将来可以考虑为事件和样本发布者都提供 tempest 测试。

文档影响

  1. 新的 Monasca Events Publisher 配置选项将被记录

    • 事件 API 端点

    • 事件批量间隔

    • 事件批量大小

    • 事件重试间隔

  2. 基于云的大小和云操作员的资源，还将记录每个配置选项的推荐值。

参考资料

[1] Monasca Events API 1.0: https://storyboard.openstack.org/#!/story/2001654

[2] Monasca Ceilometer 项目: https://github.com/openstack/monasca-ceilometer

[3] Ceilometer 数据处理和管道: https://docs.openstack.org/ceilometer/pike/admin/telemetry-data-pipelines.html

[4] Ceilometer 事件: https://docs.openstack.org/ceilometer/latest/admin/telemetry-events.html

[5] Openstack Panko: https://github.com/openstack/panko

[6] Monasca Event Format: https://github.com/openstack/monasca-events-api/blob/master/doc/api-samples/v1/req_simple_event.json

[7] Ceilometer 系统架构图: https://docs.openstack.org/ceilometer/ocata/architecture.html

[8] Monasca Events POST v1.0 API: https://github.com/openstack/monasca-events-api/blob/master/api-ref/source/events.inc

[9] 跨租户指标提交: https://github.com/openstack/monasca-agent/blob/master/docs/MonascaMetrics.md#cross-tenant-metric-submission

[10] Ceilometer pipeline yaml 文档: https://docs.openstack.org/ceilometer/latest/admin/telemetry-data-pipelines.html

[11] Panko 或 Aodh 没有未来: https://julien.danjou.info/lessons-from-openstack-telemetry-deflation/

[12] Ceilometer 事件弃用意味着 Panko 也已弃用: http://eavesdrop.openstack.org/irclogs/%23openstack-telemetry/%23openstack-telemetry.2018-10-10.log.html

[13] Ceilometer 事件在 Stein 中标记为已弃用: https://review.opendev.org/#/c/603336/