From beed59f303e1efbf8e6b6d5f7e5fc985f883a1e4 Mon Sep 17 00:00:00 2001 From: David Kretch Date: Sat, 19 Aug 2017 17:00:51 -0400 Subject: Fix trailing space in ec2_vol example, fix 'the the' typos (#28440) * Fix 'the the' typos, fix 'pahting' filename typo * Change 'the the' typos to a single 'the'. * Change `playbook_pahting.rst` to `playbook_pathing.rst`. * Delete trailing space in ec2_vol example Delete the trailing space in `instance: "{{ item.id }} "`, which makes the example fail when run because it looks for instance "i-xxxx ". --- docs/docsite/rst/guide_aws.rst | 2 +- docs/docsite/rst/playbook_pahting.rst | 41 -------------------------------- docs/docsite/rst/playbook_pathing.rst | 41 ++++++++++++++++++++++++++++++++ docs/docsite/rst/playbooks_checkmode.rst | 4 ++-- docs/docsite/rst/playbooks_filters.rst | 2 +- 5 files changed, 45 insertions(+), 45 deletions(-) delete mode 100644 docs/docsite/rst/playbook_pahting.rst create mode 100644 docs/docsite/rst/playbook_pathing.rst (limited to 'docs/docsite/rst') diff --git a/docs/docsite/rst/guide_aws.rst b/docs/docsite/rst/guide_aws.rst index 4a47fa73af..7135002dca 100644 --- a/docs/docsite/rst/guide_aws.rst +++ b/docs/docsite/rst/guide_aws.rst @@ -117,7 +117,7 @@ From this, we'll use the add_host module to dynamically create a host group cons add_host: hostname={{ item.public_ip }} groups=ec2hosts with_items: "{{ ec2.instances }}" -With the host group now created, a second play at the bottom of the the same provisioning playbook file might now have some configuration steps:: +With the host group now created, a second play at the bottom of the same provisioning playbook file might now have some configuration steps:: # demo_setup.yml diff --git a/docs/docsite/rst/playbook_pahting.rst b/docs/docsite/rst/playbook_pahting.rst deleted file mode 100644 index 491306688e..0000000000 --- a/docs/docsite/rst/playbook_pahting.rst +++ /dev/null @@ -1,41 +0,0 @@ -======================= -Search paths in Ansible -======================= - -Absolute paths are not an issue as they always have a known start, but relative paths ... well, they are relative. - -Config paths -============ - -By default these should be relative to the config file, some are specifically relative to the 'cwd' or the playbook and should have this noted in their description. Things like ssh keys are left to use 'cwd' because it mirrors how the underlying tools would use it. - - -Task paths -========== - -Here things start getting complicated, there are 2 different scopes to consider, task evalution (paths are all local, like in lookups) and task execution, which is normally on the remote, unless an action plugin is involved. - -Some tasks that require 'local' resources use action plugins (template and copy are examples of these), in which case the path is also local. - -The magic of 'local' paths --------------------------- - -Lookups and action plugins both use a special 'search magic' to find things, taking the current play into account, it uses from most specific to most general the the playbook dir in which a task is contained (this includes roles and includes). - -Using this magic, relative paths get attempted first with a 'files|templates|vars' appended (if not already present), depending on action being taken, 'files' is the default. (i.e include_vars will use vars/). The paths will be searched from most specific to most general (i.e role before play). -dependent roles WILL be traversed (i.e task is in role2, role2 is a dependency of role1, role2 will be looked at first, then role1, then play). -i.e :: - - role search path is rolename/{files|vars|templates}/, rolename/tasks/. - play search path is playdir/{files|vars|templates}/, playdir/. - - -The current working directory (cwd) is not searched. If you see it, it just happens to coincide with one of the paths above. -If you `include` a task file from a role, it will NOT trigger role behavior, this only happens when running as a role, `include_role` will work. -A new variable `ansible_search_path` var will have the search path used, in order (but without the appended subdirs). Using 5 "v"s (`-vvvvv`) should show the detail of the search as it happens. - -As for includes, they try the path of the included file first and fall back to the play/role that includes them. - - - -.. note: The 'cwd' might vary depending on the connection plugin and if the action is local or remote. For the remote it is normally the directory on which the login shell puts the user. For local it is either the directory you executed ansible from or in some cases the playbook directory. diff --git a/docs/docsite/rst/playbook_pathing.rst b/docs/docsite/rst/playbook_pathing.rst new file mode 100644 index 0000000000..9dd213d251 --- /dev/null +++ b/docs/docsite/rst/playbook_pathing.rst @@ -0,0 +1,41 @@ +======================= +Search paths in Ansible +======================= + +Absolute paths are not an issue as they always have a known start, but relative paths ... well, they are relative. + +Config paths +============ + +By default these should be relative to the config file, some are specifically relative to the 'cwd' or the playbook and should have this noted in their description. Things like ssh keys are left to use 'cwd' because it mirrors how the underlying tools would use it. + + +Task paths +========== + +Here things start getting complicated, there are 2 different scopes to consider, task evalution (paths are all local, like in lookups) and task execution, which is normally on the remote, unless an action plugin is involved. + +Some tasks that require 'local' resources use action plugins (template and copy are examples of these), in which case the path is also local. + +The magic of 'local' paths +-------------------------- + +Lookups and action plugins both use a special 'search magic' to find things, taking the current play into account, it uses from most specific to most general playbook dir in which a task is contained (this includes roles and includes). + +Using this magic, relative paths get attempted first with a 'files|templates|vars' appended (if not already present), depending on action being taken, 'files' is the default. (i.e include_vars will use vars/). The paths will be searched from most specific to most general (i.e role before play). +dependent roles WILL be traversed (i.e task is in role2, role2 is a dependency of role1, role2 will be looked at first, then role1, then play). +i.e :: + + role search path is rolename/{files|vars|templates}/, rolename/tasks/. + play search path is playdir/{files|vars|templates}/, playdir/. + + +The current working directory (cwd) is not searched. If you see it, it just happens to coincide with one of the paths above. +If you `include` a task file from a role, it will NOT trigger role behavior, this only happens when running as a role, `include_role` will work. +A new variable `ansible_search_path` var will have the search path used, in order (but without the appended subdirs). Using 5 "v"s (`-vvvvv`) should show the detail of the search as it happens. + +As for includes, they try the path of the included file first and fall back to the play/role that includes them. + + + +.. note: The 'cwd' might vary depending on the connection plugin and if the action is local or remote. For the remote it is normally the directory on which the login shell puts the user. For local it is either the directory you executed ansible from or in some cases the playbook directory. diff --git a/docs/docsite/rst/playbooks_checkmode.rst b/docs/docsite/rst/playbooks_checkmode.rst index a7831d9b68..3b37769a60 100644 --- a/docs/docsite/rst/playbooks_checkmode.rst +++ b/docs/docsite/rst/playbooks_checkmode.rst @@ -33,7 +33,7 @@ There are two options: 1. Force a task to **run in check mode**, even when the playbook is called **without** ``--check``. This is called ``check_mode: yes``. 2. Force a task to **run in normal mode** and make changes to the system, even when the playbook is called **with** ``--check``. This is called ``check_mode: no``. -.. note:: Prior to version 2.2 only the the equivalent of ``check_mode: no`` existed. The notation for that was ``always_run: yes``. +.. note:: Prior to version 2.2 only the equivalent of ``check_mode: no`` existed. The notation for that was ``always_run: yes``. Instead of ``yes``/``no`` you can use a Jinja2 expression, just like the ``when`` clause. @@ -51,7 +51,7 @@ Example:: Running single tasks with ``check_mode: yes`` can be useful to write tests for -ansible modules, either to test the module itself or to the the conditions under +ansible modules, either to test the module itself or to the conditions under which a module would make changes. With ``register`` (see :doc:`playbooks_conditionals`) you can check the potential changes. diff --git a/docs/docsite/rst/playbooks_filters.rst b/docs/docsite/rst/playbooks_filters.rst index 7e6c2c3969..534a9afacf 100644 --- a/docs/docsite/rst/playbooks_filters.rst +++ b/docs/docsite/rst/playbooks_filters.rst @@ -6,7 +6,7 @@ Filters Filters in Ansible are from Jinja2, and are used for transforming data inside a template expression. Jinja2 ships with many filters. See `builtin filters`_ in the official Jinja2 template documentation. -Take into account that templating happens on the the Ansible controller, **not** on the task's target host, so filters also execute on the controller as they manipulate local data. +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. -- cgit v1.2.1