Marcus Klein 2ccc59fa13 document the removal of keys in ini files
which requires an empty dictionary in playbook YAML config_overrides
parameter

Change-Id: I3ab9c434883e743738b3e06d54c3c54c84bc7217
2022-09-28 15:18:41 +02:00

4.4 KiB

Config Template collection

Synopsis

Renders template files providing a create/update override interface

  • The module contains the template functionality with the ability to override items in config, in transit, through the use of a simple dictionary without having to write out various temp files on target machines. The module renders all of the potential jinja a user could provide in both the template file and in the override dictionary which is ideal for deployers who may have lots of different configs using a similar code base.
  • The module is an extension of the copy module and all of attributes that can be set there are available to be set here.

Examples

Example for .conf

The config_template collection has a variety of tools available. A .conf file may include options that are not normally supported in an INI file, but are used in OpenStack, like ListOpt and MultiStrOpt.

Even though we are generating a .conf file, we specify the config_type of `ini` when using config_template.

Playbook:

  • hosts: localhost connection: local gather_facts: no tasks: - openstack.config_template.config_template: content: | [foo] bar = baz

    [section1] option1 = value1 option2 = value2 dest: "test_dst.conf" config_type: "ini" config_overrides: hello: cruel: world section1: option1: value2 option2: {} orderedListSection: listOpt: - listItem1 - listItem2 multiStrOpSection: multiStrOpOption: ? multiStrOp1 ? multiStrOp2

Resulting file on the remote host:

[foo] bar = baz

[section1] option1 = value2

[hello] cruel = world

[orderedListSection] listOpt = listItem1,listItem2

[multiStrOpSection] multiStrOpOption = multiStrOp1 multiStrOpOption = multiStrOp2

Take notice of the option2 in section1, which is removed in the output but requires an empty dictionary in the playbook YAML. The empty dictionary is translated to None value and the default behavior is to remove keys with None values. See parameter ignore_none_type, which defaults to true.

A practical example would be for something like OpenStack's nova.conf where the input of:

nova_conf_override:
filter_scheduler:
enabled_filters:
  • ComputeFilter
  • NUMATopologyFilter
pci:
? passthrough_whitelist: '{"address":":0a:00.",

"physical_network":"pn1"}'

? passthrough_whitelist: '{"vendor_id":"1137","product_id":"0071"}'

Would produce:

[filter_scheduler] enabled_filters = ComputeFilter,NUMATopologyFilter

[pci] passthrough_whitelist = '{"address":":0a:00.", "physical_network":"pn1"}' passthrough_whitelist = '{"vendor_id":"1137","product_id":"0071"}'

Example for .ini with remote_src

The remote_src: true argument instructs config_template to use a file that is already on the remote host as the source content.

Input file on the remote host:

[foo] # comment bar = baz

[hello]

Playbook:

  • hosts: remote_host gather_facts: no tasks: - config_template: remote_src: true src: "/etc/test_src.ini" dest: "/etc/test_dst.ini" config_type: "ini" config_overrides: hello: cruel: world

Resulting file on the remote host:

[foo] # comment bar = baz

[hello] cruel = world

Installing collection

To use the collection, include this in your meta/main.yml:

collections:
  • openstack.config_template

Also the Ansible requirement file can be used with the ansible-galaxy command to automatically fetch the collections for you in a given project. To do this add the following lines to your requirements.yml file.

../../examples/ansible-role-requirements.yml

After that simple run the following command to get requirements installed:

$ ansible-galaxy install -r requirements.yml