合并 Monasca APIs

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

目前 Monasca 有 3 个 API：一个用于指标，一个用于日志，一个用于事件。从历史上看，这给开发者升级或添加新功能、系统管理员配置 API 以及打包者生成 Monasca 发行版带来了额外的开销。本规范的目的是考虑是否应该将 Monasca API 合并为一个统一的 API。

问题描述

Monasca API 使用 Python 编写，并共享很多功能，其中一部分（但并非全部）已被分解到 Monasca 通用库中。这便是第一个问题所在

  1. 存在大量的技术债务。

有大量的通用功能尚未分解到 Monasca 通用库中。例如，Monasca API 仓库包含用于验证指标的代码，Monasca 通用库也包含。对于查询授权也是如此，验证代码存在于两个仓库中。当然，这些技术债务可以解决，但它是如何产生的？

  1. 更新 API 以支持通用功能，与更新单个 API 相比，会给开发者和审查者带来显著的开销。

所有 API 的编写方式略有不同。将 Oslo Policy 或 uWSGI 的支持添加到某个 API，并不等同于将其添加到另一个 API。此外，更改通常需要在多个仓库中进行。虽然 Zuul 适合协调这项任务，但它需要开发者仔细同步版本，并得到审查者的细致关注。如果修改了所有三个 API 都通用的代码，则必须系统地验证在每种情况下更改是否按预期工作。当然，自动化测试可以在这里提供帮助，但并不能完全消除负担。

  1. 从历史上看，很难在多个 API 中保持一致的体验。

有时，API 会在理想情况下不应如此的情况下发生分歧。例如，在添加对通用功能的支持时，工作传统上侧重于一个 API 以简化任务，并计划稍后为其他 API 添加支持。如果工作停止，例如由于发布或开发者离职，API 可能会在很长一段时间内保持分歧状态。当然，一种解决方案是在所有三个 API 中完成工作并且所有通用代码都添加到 Monasca 通用库之前，阻止合并通用功能。实际上，由于可用的人力资源数量，这已被阻止。例如，贡献者可能只对指标感兴趣。他们可能无法证明花时间在其他 API 上是合理的。

  1. 打包、部署和配置 3 个 API 比部署单个统一的 API 更复杂。

这显而易见，但可能会因 3) 而变得更糟。例如，从历史上看，并非总是能够以相同的方式运行所有 API。Kafka 等通用功能的配置并不总是统一的。有额外的构建系统配置，需要注册的额外的 keystone 端点，以及监控 3 个 API 的可用性比监控一个 API 更困难。

用例

作为开发者，我可以通过在单个仓库中实现所有 API 通用的功能来节省时间，而不是在四个仓库中。

作为审查者，我可以通过不必考虑更改如何影响多个仓库来节省时间。

作为部署者，我可以通过减少两个需要部署和配置的服务来节省时间。

作为安全分析师，我可以专注于审查单个 API，而不是三个。

作为 Monasca 的用户，我希望获得一致的体验，包括可用性和文档。

作为打包者，我希望有一个 Monasca API，而不是三个，以节省配置和维护构建系统的时间。

提议的变更

将所有 API 合并到一个统一的 API 中。将所有来自 Monasca 通用仓库的通用 API 代码合并到统一的 API 仓库中。具体来说，建议将所有相关代码合并到 Monasca API 中。

备选方案

  1. 重构所有 API，使代码标准化。在所有 API 中完成工作并且所有通用代码都被分解到 Monasca 通用库之前，阻止合并通用功能。从历史经验来看，如果没有额外的开发者，这将很困难。

  2. 什么也不做，继续解决技术债务。从长远来看，这可能会使添加新功能更加困难，并需要更多的时间进行维护。

数据模型影响

无

REST API 影响

除了单个服务将实现所有 API 的组合模式之外，调用不应更改。在合并时，例如维度验证代码，我们应该小心不要破坏在一个 API 中接受但另一个 API 中未接受的内容。理想的结果是，我们对所有 API 调用使用相同的代码来解析通用字段，例如维度。

安全影响

如果先前公开了单个 API，则部署统一的 API 将增加攻击面。但是，通常情况下，由于减少了开发者和审查者的开销，因此更容易审查更改以进行安全改进。

在事件和日志 API 的弃用期间，可能需要将对统一 API 所做的安全修复程序回溯。

其他最终用户影响

所有与 Monasca 事件和日志 API 通信的服务都需要定向到统一的 API。对于使用 Keystone 查找 Monasca 端点的服务，这应该自动发生。其他服务，例如 Fluentd Monasca 输出插件，需要手动重新配置。一种可能性是提供一个宽限期，在此期间仍然支持 Monasca 事件和日志 API，以使过渡更容易。

性能影响

没有直接影响。

通常，对单个 API 进行分析和优化比对所有三个 API 进行分析和优化要少费力。

在具有专用节点（例如，专用的日志节点，托管 Monasca 日志 API）的集群部署中，统一的 API 可以作为直接替换部署，并且可以简单地忽略附加功能。

其他部署者影响

对于支持旧版本 Monasca 的 Monasca 用户，可能需要将对统一 API 所做的任何安全或错误修复程序回溯到各个 API。

所有正在积极维护的部署解决方案都需要更新以部署统一的 API。例如，Monasca-Docker、DevStack、Kolla、OpenStack Ansible 和 Helm。

在 DevStack 的情况下，我们应该将三个现有插件合并为一个插件。生成的插件应该具有诸如 log_pipeline_enabled 和 metrics_pipeline_enabled 之类的选项，以支持单独启用这些管道。例如，当 DevStack 用于 OpenStack CI 时，这对于允许更有效地测试针对特定区域的更改非常有用。

开发者影响

进行此更改的动机是减少在改进 Monasca API 时对开发者和审查者造成的负担。希望这能提高开发者的生产力。

实现

负责人

主要负责人

<launchpad-id 或 None>

其他贡献者

<launchpad-id 或 None>

工作项

  • 审查 API 的测试覆盖率，并添加任何缺失区域的覆盖率。

  • 审查 Monasca 通用库的测试覆盖率，并添加任何缺失区域的覆盖率。

  • 将 Monasca 通用 Python 代码合并到 Monasca API 中。通用功能应包括

    • 授权

    • 验证

    • OpenStack 策略

    • WSGI 部署

  • 在 Monasca API 中实现日志 API 模式并移植测试。

  • 实现事件 API 模式并移植测试。

  • 将 DevStack 插件合并到一个插件中，并添加支持单独启用管道的功能。

  • 弃用 Monasca 日志和事件 API。

  • 合并和更新文档

依赖项

没有添加额外的依赖项。可以删除对 Monasca 通用库的依赖。

测试

Monasca API 和日志 API Tempest 测试插件已经合并到一个插件中。任何存在于事件 API 的 Tempest 测试也应合并到统一的插件中。Tempest 插件需要更新以使用统一的 API。

日志 API 和事件 API 仓库中的单元测试需要移植到 Monasca API（统一）仓库。其中一些测试可能是不必要的。

文档影响

三个文档集将被减少到一个。虽然合并文档需要一些努力，但希望它会更加一致。

参考资料

无

历史记录

无