可插拔的库存后端

日期:

2016-12-13 22:00

标签:

库存, craton

本规范旨在为将现有的库存系统从单一的、紧耦合的文件系统接口迁移到支持多种存储后端的插拔式系统提供指导和长期目标。

目前，生成的库存保存在一个地方 - 部署节点上的 /etc/openstack_deploy/openstack_inventory.json 文件中。虽然这可行，但它不够健壮。为了适应更多的部署灵活性，应该重构库存系统以使用插拔式系统来存储必要的信息。文件系统插件将提供向后兼容性，并且还将开发一个 Craton 插件。

问题描述

虽然当前代码库中存在多个需要解决的问题，但本规范仅关注库存事实的存储。

自 OpenStack-Ansible 在 Icehouse 中创建以来，完成的库存的真相来源一直是 /etc/openstack_deploy/openstack_inventory.json 文件。虽然这可行，但它有一些缺点

  • 作为一个单独的文件，它可能会被意外删除。如果配置文件已更改，由于 UUID 后缀，在没有 tar 备份文件的情况下无法获得确切的副本。

  • 只有 UNIX 文件权限管理对文件的访问。

  • 除了简单的 tar 备份之外，不存在更改记录。这对于运行集群的文档和审计很有用。

本规范不旨在定义一个完全健壮的库存管理系统。相反，OpenStack-Ansible 库存系统可以更加模块化，尤其是在其存储方面，以便部署者可以利用其他专用系统。

这样做需要重构动态库存生成代码，以便存储问题（例如写入输出和读取先前运行的输出）不再直接与值的生成相关联。

提议的变更

当前与文件系统接口的任何代码都将被移动到它自己的 Python 模块中，以便它与生成逻辑分开存在。这项工作已经在进行中，并且不需要特定的插件系统才能完成。

完成此操作后，将使用插件系统提供一个通用的存储操作接口，供代码库的其余部分使用。此代码将连接到插件库，并返回兼容的存储插件实例。

插件 Python API

插件应支持以下公共方法

register

在插件系统中注册插件。接收为插件指定的所有参数的字典，并应提取其需要的任何信息，例如文件位置、连接字符串或 URL。

load

将数据从源加载到当前动态库存脚本中的 Python 字典中。源可以是文件、数据库或任何其他后端系统。

write

将库存字典写入指定的后端。接收库存字典作为参数

配置更改

可能需要向用户呈现一些新的配置，以便可以识别用于存储的适当插件。由于脚本的工作包括访问该文件，因此这种配置不适合 etc/openstack_deploy/openstack_user_config_file。

相反，建议使用 /etc/ansible/osa.ini 文件，以匹配 Ansible 的动态库存文档 中 ec2.py 脚本的方法。

此文件的具体格式将留给实施审查，但从高级别来看，它可能包括要使用的库存模块的 Python 导入路径，以及它可能需要的任何设置，例如连接字符串或 API URL。

备选方案

什么都不做，库存可以继续依赖 JSON 后端；到目前为止，它一直可靠地工作。但是，其固有的问题仍然存在。

在当前状态下，部署者必须分叉存储库以修改动态库存代码，这从长远来看是一种维护负担，可能不可持续。

替代库存脚本也可以放置在 playbooks/inventory 中，替换或添加到当前的 dynamic_inventory.py 文件。替换可能或可能不使用当前的 openstack_user_config.yml 文件和环境结构。附加脚本将生成从所有来源合并的输出，使用 os.listdir 读取，然后根据字母数字文件名进行处理。（参见 Ansible 脚本加载器）。

配置替代方案

而不是 /etc/ansible/osa.ini 文件，可以使用环境变量来设置插件选项。

插件实施替代方案

现有的插件实施包括 PluginBase 和 Stevedore。

Stevedore 是 OpenStack 项目，使用它将使项目与社区更加紧密地保持一致。Stevedore 需要通过 setup.py entry_points 注册插件。OpenStack-Ansible 的 setup.cfg 需要进行修改才能安装 python 代码，并且 lib 目录需要重命名才能在 pbr 的设计中工作。已经提交了针对这些更改的 原型审查 <https://review.openstack.org/#/c/418076/>。

PluginBase 不是 OpenStack 生态系统的一部分，但它是一个简单、独立的插件系统。它没有外部依赖项，可以通过标准的 Python 导入系统使用，而无需为我们现有的代码提供 setup.py 文件。

PluginBase 方法对树内代码的影响较小，但是任何外部插件都应该可以通过 pip 安装，因此需要一个 setup.py。因此，两者都是可行的实施选项，Stevedore 需要更多的前期工作。

Playbook/Role 影响

理想情况下，playbook 的影响应该最小或不存在。生成的库存应该看起来相同，无论使用什么后端插件。

升级影响

应该提供从现有 JSON 来源迁移的路径，以便现有环境可以迁移到新系统（如果他们选择）。但是，迁移可能涉及特定于系统的实施细节知识，因此每个系统可能都需要其自己的导入功能。

已经实施了一个 导出函数，以提供每主机格式的库存。这可以用作外部系统在其自己的导入系统中使用的一种基础。

此导出/导入过程假定在 playbook 运行之外进行。

安全影响

此更改引入了与外部系统的通信 - 这样做存在固有的风险。假设这些系统使用安全通道并受部署者信任。

理论上，秘密可以存储在这些后端中，但 openstack-ansible.sh 包装脚本当前引用 user_secrets.yml 文件，而不是将其放置在库存中。系统不应规定这是秘密的唯一解决方案，但是。部署者选择将这些放在哪里由他们决定，但将秘密存储在任何未加密或未保护的后端中是不建议的。

性能影响

根据用作后端的系统，库存生成或查找可能需要更长的时间。如果通过网络接口使用所述系统，则延迟和缓存是问题。

由于此类别非常广泛，并且不同的系统将具有不同的特征，因此最好将更多细节留给特定的插件实施。

最终用户影响

部署云的用户，那些使用虚拟机和网络的用户，不应该看到太大的差异。此更改主要是为了促进部署者的问题。

部署者影响

部署者可能拥有全新的库存后端源。需要提供读取所述源的配置选项。默认情况下，树内实施可能仍然是 JSON 文件。

更改现有集群将需要部署者干预以将相关数据从文件迁移到新系统，该系统可能由 OpenStack-Ansible 部署外部管理。

任何依赖于 openstack_inventory.json 文件的辅助脚本都需要进行修改，最好利用新的插件/API。

inventory-manage.py 脚本当前仅为 JSON 文件提供管理界面，不打算成为通用的库存管理工具。不同的系统将拥有自己的客户端或前端来执行此类管理和查询。

开发人员影响

角色开发人员应该能够依赖于库存信息保持不变。

从事库存生成的工作的开发人员必须考虑来自多个后端的数据源，但是目标是为使用该数据提供统一的 API。

依赖项

虽然不是严格的依赖关系，但这与 dynamic inventory lib 蓝图/规范密切相关。它专门试图解决外部后端的问题。

实现

负责人

主要负责人

nolan-brubaker (IRC: palendae)

其他贡献者

steve-lewis (IRC: stevelle)

工作项

  • 将现有代码作为单独的模块实施。这项工作已经基本完成，请参见代码审查 https://review.openstack.org/#/c/392056/、https://review.openstack.org/392417 和 https://review.openstack.org/399303。

  • 实施插件系统。无论是 Stevedore 还是 PluginBase，都需要编写与系统接口的代码。

  • 将文件系统代码作为插件实施。这可以与上一项同时完成，以便充分测试它。

测试

应编写单元和集成测试，以确保现有的 JSON 代码继续工作。此外，应编写示例插件以练习该系统，即使它们是“虚拟”系统。

由于这适合库存测试，因此不应影响集成的构建时间。它也应逐次提交进行测试。

集成构建也会进行测试，但并不一定针对易于故障排除。

存储库外部的单个插件需要单独进行门控。

文档影响

应提供有关编写插件和迁移到新系统的指导

参考资料

本规范受到以下 etherpad 讨论的启发

  • https://etherpad.openstack.org/p/osa-dynamicinventory-plugins

  • https://etherpad.openstack.org/p/craton_osa

  • https://etherpad.openstack.org/p/openstack-ansible-newton-dynamic-inventory