mirror of
https://github.com/ansible-collections/community.general.git
synced 2024-09-14 20:13:21 +02:00
Correct docsite typos: it's -> its (#50812)
This commit is contained in:
parent
0e7a9a2771
commit
88029a73d6
5 changed files with 5 additions and 5 deletions
|
@ -198,7 +198,7 @@ Inventory source common format
|
|||
------------------------------
|
||||
|
||||
To simplify development, most plugins use a mostly standard configuration file as the inventory source, YAML based and with just one required field ``plugin`` which should contain the name of the plugin that is expected to consume the file.
|
||||
Depending on other common features used, other fields might be needed, but each plugin can also add it's own custom options as needed.
|
||||
Depending on other common features used, other fields might be needed, but each plugin can also add its own custom options as needed.
|
||||
For example, if you use the integrated caching, ``cache_plugin``, ``cache_timeout`` and other cache related fields could be present.
|
||||
|
||||
.. _inventory_development_auto:
|
||||
|
|
|
@ -312,7 +312,7 @@ For example:
|
|||
|
||||
Suggestions to resolve:
|
||||
|
||||
* If you are using the ``provider:`` options ensure that it's suboption ``host:`` is set correctly.
|
||||
* If you are using the ``provider:`` options ensure that its suboption ``host:`` is set correctly.
|
||||
* If you are not using ``provider:`` nor top-level arguments ensure your inventory file is correct.
|
||||
|
||||
|
||||
|
|
|
@ -178,7 +178,7 @@ Display class
|
|||
-------------
|
||||
|
||||
As of Ansible 2.8, the ``Display`` class is now a "singleton". Instead of using ``__main__.display`` each file should
|
||||
import and instantiate ``ansible.utils.display.Display`` on it's own.
|
||||
import and instantiate ``ansible.utils.display.Display`` on its own.
|
||||
|
||||
**OLD** In Ansible 2.7 (and earlier) the following was used to access the ``display`` object:
|
||||
|
||||
|
|
|
@ -10,7 +10,7 @@ Filters in Ansible are from Jinja2, and are used for transforming data inside a
|
|||
|
||||
Take into account that templating happens on the Ansible controller, **not** on the task's target host, so filters also execute on the controller as they manipulate local data.
|
||||
|
||||
In addition the ones provided by Jinja2, Ansible ships with it's own and allows users to add their own custom filters.
|
||||
In addition the ones provided by Jinja2, Ansible ships with its own and allows users to add their own custom filters.
|
||||
|
||||
.. _filters_for_formatting_data:
|
||||
|
||||
|
|
|
@ -155,7 +155,7 @@ Or, using the newer syntax::
|
|||
app_port: 5000
|
||||
...
|
||||
|
||||
You can conditionally import a role and execute it's tasks::
|
||||
You can conditionally import a role and execute its tasks::
|
||||
|
||||
---
|
||||
|
||||
|
|
Loading…
Reference in a new issue