mirror of
https://github.com/ansible-collections/community.general.git
synced 2024-09-14 20:13:21 +02:00
minor doc fixes
This commit is contained in:
parent
01d835700b
commit
b0bed27211
5 changed files with 10 additions and 7 deletions
|
@ -174,7 +174,9 @@ How do I loop over a list of hosts in a group, inside of a template?
|
|||
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
A pretty common pattern is to iterate over a list of hosts inside of a host group, perhaps to populate a template configuration
|
||||
file with a list of servers. To do this, you can just access the "$groups" dictionary in your template, like this::
|
||||
file with a list of servers. To do this, you can just access the "$groups" dictionary in your template, like this:
|
||||
|
||||
.. code-block:: jinja2
|
||||
|
||||
{% for host in groups['db_servers'] %}
|
||||
{{ host }}
|
||||
|
@ -184,7 +186,7 @@ If you need to access facts about these hosts, for instance, the IP address of e
|
|||
|
||||
- hosts: db_servers
|
||||
tasks:
|
||||
- # doesn't matter what you do, just that they were talked to previously.
|
||||
- debug: msg="doesn't matter what you do, just that they were talked to previously."
|
||||
|
||||
Then you can use the facts inside your template, like this::
|
||||
|
||||
|
|
|
@ -228,7 +228,7 @@ Allows disabling of deprecating warnings in ansible-playbook output::
|
|||
|
||||
Deprecation warnings indicate usage of legacy features that are slated for removal in a future release of Ansible.
|
||||
|
||||
.. _display_args_to_stdout
|
||||
.. _display_args_to_stdout:
|
||||
|
||||
display_args_to_stdout
|
||||
======================
|
||||
|
@ -768,7 +768,7 @@ instead. Setting it to False will improve performance and is recommended when h
|
|||
|
||||
record_host_keys=True
|
||||
|
||||
.. _paramiko_proxy_command
|
||||
.. _paramiko_proxy_command:
|
||||
|
||||
proxy_command
|
||||
=============
|
||||
|
|
|
@ -5,14 +5,14 @@ Advanced Syntax
|
|||
|
||||
This page describes advanced YAML syntax that enables you to have more control over the data placed in YAML files used by Ansible.
|
||||
|
||||
.. _yaml_tags_and_python_types
|
||||
.. _yaml_tags_and_python_types:
|
||||
|
||||
YAML tags and Python types
|
||||
``````````````````````````
|
||||
|
||||
The documentation covered here is an extension of the documentation that can be found in the `PyYAML Documentation <http://pyyaml.org/wiki/PyYAMLDocumentation#YAMLtagsandPythontypes>`_
|
||||
|
||||
.. _unsafe_strings
|
||||
.. _unsafe_strings:
|
||||
|
||||
Unsafe or Raw Strings
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
|
@ -936,7 +936,7 @@ how all of these things can work together.
|
|||
Advanced Syntax
|
||||
```````````````
|
||||
|
||||
For information about advanced YAML syntax used to declare variables and have more control over the data placed in YAML files used by Ansible, see `playbooks_advanced_syntax`_
|
||||
For information about advanced YAML syntax used to declare variables and have more control over the data placed in YAML files used by Ansible, see `:doc:playbooks_advanced_syntax`
|
||||
|
||||
.. seealso::
|
||||
|
||||
|
|
|
@ -163,6 +163,7 @@ Here are some corner cases encountered when updating, these are mostly caused by
|
|||
|
||||
- task: dostuf
|
||||
becom: yes
|
||||
|
||||
The task always ran without using privilege escalation (for that you need `become`) but was also silently ignored so the play 'ran' even though it should not, now this is a parsing error.
|
||||
|
||||
|
||||
|
|
Loading…
Reference in a new issue