
which requires an empty dictionary in playbook YAML config_overrides parameter Change-Id: I3ab9c434883e743738b3e06d54c3c54c84bc7217
181 lines
4.4 KiB
ReStructuredText
181 lines
4.4 KiB
ReStructuredText
==========================
|
|
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:
|
|
|
|
.. code-block :: yaml
|
|
|
|
- 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:
|
|
|
|
.. code-block :: ini
|
|
|
|
[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:
|
|
|
|
.. code-block :: yaml
|
|
|
|
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:
|
|
|
|
.. code-block :: ini
|
|
|
|
[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:
|
|
|
|
.. code-block :: ini
|
|
|
|
[foo]
|
|
# comment
|
|
bar = baz
|
|
|
|
[hello]
|
|
|
|
Playbook:
|
|
|
|
.. code-block :: yaml
|
|
|
|
- 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:
|
|
|
|
.. code-block :: ini
|
|
|
|
[foo]
|
|
# comment
|
|
bar = baz
|
|
|
|
[hello]
|
|
cruel = world
|
|
|
|
Installing collection
|
|
---------------------
|
|
|
|
To use the collection, include this in your meta/main.yml:
|
|
|
|
.. code-block :: yaml
|
|
|
|
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.
|
|
|
|
.. literalinclude:: ../../examples/ansible-role-requirements.yml
|
|
:language: yaml
|
|
|
|
After that simple run the following command to get requirements installed:
|
|
|
|
.. code-block :: shell
|
|
|
|
$ ansible-galaxy install -r requirements.yml
|