可调 OpenStack 配置

日期:

2015-08-26

标签:

openstack, 配置, 调优

与其在每个角色中为每个可能的/期望的配置条目实现一个特定的变量,不如采用一种更通用的方法,使部署者能够实现给定角色所需的任何有效的配置条目。OpenStack Ansible 只需要实现与标准 OpenStack 默认设置的偏差。这些设置的例子包括使服务正常工作的最低设置和最佳实践设置。对模板的更改将使项目能够以扁平化或其他最小动态化的方式发布配置文件,从而限制给定角色中变量数量的庞大范围。

此实现旨在

  • 减少项目需要携带的变量数量,仅仅是为了启用部署者请求的自定义设置。

  • 减少项目需要在底层 OpenStack 环境的每次主要升级中处理的配置文件设置数量。

  • 缩短部署者在 OpenStack 配置文件中实现附加配置项的周转时间。

问题描述

OpenStack Ansible 项目当前在角色中携带了大量的变量,仅仅是为了启用覆盖 OpenStack 默认设置的能力。这是不必要的冗余,每当项目开始使用更新版本的 OpenStack 时,都必须对其进行审查以确定已弃用的选项。

它还引入了一个不必要的提议/开发/测试/发布周期,用于对配置文件进行简单的更改,如果部署者被授权这样做,这些更改可以轻松完成。

提议的变更

  • 将创建一个新的 Ansible action plugin,它将促进模板动态更新的能力。此更改将基于现有的 Ansible 模板功能,但允许通过简单的字典数据结构应用更改。更新在传输过程中应用于模板,从而使我们能够携带最少的代码,同时利用所有已构建的 Ansible 功能。

  • 名为“config_template”的 action plugin 将添加两种新的输入类型 config_dataconfig_type。新的输入选项将是可选的,允许我们简单地用 config_template 模块替换我们当前的模板任务。

  • 新的默认值将作为空字典创建,作为部署者覆盖配置项的基础入口点。

从代码角度来看,对模板任务的更改如下所示

- name: run config template ini
  config_template:
    src: templates/test.ini.j2
    dest: /tmp/test.ini
    config_data: {'data': 'things'}
    config_type: ini

- name: run config template json
  config_template:
    src: templates/test.json.j2
    dest: /tmp/test.json
    config_data: {'data': 'things'}
    config_type: json

- name: run config template yaml
  config_template:
    src: templates/test.yaml.j2
    dest: /tmp/test.yaml
    config_data: {'data': 'things'}
    config_type: yaml
需要注意的是

用于更新或覆盖配置模板中条目的字典。字典数据结构可以是嵌套的。如果目标配置文件是 ini 文件,则 config_data 中的嵌套键将用作节标题。

备选方案

继续使用当前范例,为每个可配置的配置文件条目添加一个 ansible 变量。

Playbook 影响

现有的角色需要进行调整,以支持新的 config_data 入口点,并且相关的模板任务需要更新到 config_template 模块。

升级影响

此更改不会影响当前的升级,因为所有模板中的所有内容都可以保持不变。拟议的模块更改只是使部署者能够在需要时更新模板,而无需在树中进行更改。在未来的版本中,我们可以根据需要或要求弃用我们当前携带的变量,同时仍然保持通过使用 config_template 模块根据需要覆盖选项的能力。

安全影响

无。

性能影响

无。

最终用户影响

部署者影响

部署者将能够根据需要动态更新配置选项,而无需在树中进行更改。这将允许部署者根据需要更好地定制部署。

开发人员影响

这将减少开发人员参与小型补丁的需求,这些补丁实现了部署者希望使用的基本配置文件条目。

依赖项

无。

实现

负责人

主要负责人

https://launchpad.net/~kevin-carter IRC: cloudnull

其他贡献者

目前没有。

工作项

为以下格式的所有配置文件实现可调配置:[yaml, json, ini]

  • 开发 Ansible Action Plugin,以启用对现有模板进行飞行配置更改的能力。

  • 将角色中删除配置文件的所有模板任务更改为使用新的 config_template 模块。

  • config_template 模块替换 copy_update 模块。

测试

在当前的门控测试中,我们可以添加一个基本的模板测试来覆盖一些选项/添加一些选项,并断言来自基本模板的更改已经发生。这可以使用示例任务中的项目以及简单的 json、ini 和 yaml 数据结构来完成。我们还可以设置门控覆盖,我们知道我们希望在我们的部署中运行,以便我们练习我们试图通过门控启用的 OpenStack 代码路径。通过这种方式,我们也许可以减少我们的门控脚本变量。

文档影响

虽然 Action Plugin 具有其自身的文档,但按照正常的 Ansible 模块文档流程,我们还可以更新我们的通用安装文档,以引用新模块的存在及其工作方式。我想避免记录每个覆盖入口点,因为这些类型项目的权威来源将是角色“defaults”本身。

参考资料