[doc] import_role: mention version from which behavior changed and fix some typos (#43843)

* [doc] fix some typos

* [doc] import_role: mention version from which behavior changed
pull/43887/head
Pilou 6 years ago committed by Matt Martz
parent 59cd693218
commit 32eab149b6

@ -31,7 +31,7 @@ include_role and import_role variable exposure
In Ansible 2.7 a new module argument named ``public`` was added to the ``include_role`` module that dictates whether or not the role's ``defaults`` and ``vars`` will be exposed outside of the role, allowing those variables to be used by later tasks. This value defaults to ``public: False``, matching current behavior. In Ansible 2.7 a new module argument named ``public`` was added to the ``include_role`` module that dictates whether or not the role's ``defaults`` and ``vars`` will be exposed outside of the role, allowing those variables to be used by later tasks. This value defaults to ``public: False``, matching current behavior.
``import_role`` does not support the ``public`` argument, and will unconditionally expose the role's ``defaults`` and ``vars`` to the rest of the playbook. This functinality brings ``import_role`` into closer alignment with roles listed within the ``roles`` header in a play. ``import_role`` does not support the ``public`` argument, and will unconditionally expose the role's ``defaults`` and ``vars`` to the rest of the playbook. This functionality brings ``import_role`` into closer alignment with roles listed within the ``roles`` header in a play.
There is an important difference in the way that ``include_role`` (dynamic) will expose the role's variables, as opposed to ``import_role`` (static). ``import_role`` is a pre-processor, and the ``defaults`` and ``vars`` are evaluated at playbook parsing, making the variables available to tasks and roles listed at any point in the play. ``include_role`` is a conditional task, and the ``defaults`` and ``vars`` are evaluated at execution time, making the variables available to tasks and roles listed *after* the ``include_role`` task. There is an important difference in the way that ``include_role`` (dynamic) will expose the role's variables, as opposed to ``import_role`` (static). ``import_role`` is a pre-processor, and the ``defaults`` and ``vars`` are evaluated at playbook parsing, making the variables available to tasks and roles listed at any point in the play. ``include_role`` is a conditional task, and the ``defaults`` and ``vars`` are evaluated at execution time, making the variables available to tasks and roles listed *after* the ``include_role`` task.

@ -56,8 +56,9 @@ options:
default: 'no' default: 'no'
notes: notes:
- Handlers are made available to the whole play. - Handlers are made available to the whole play.
- Variables defined in C(vars) and C(default) for the role are exposed at playbook parsing time. Due to this, - "Since Ansible 2.7: variables defined in C(vars) and C(defaults) for the role are exposed at playbook parsing time.
these variables will be accessible to roles and tasks executed before the the location of the C(import_role) task. Due to this, these variables will be accessible to roles and tasks executed before the location of the
C(import_role) task."
- Unlike C(include_role) variable exposure is not configurable, and will always be exposed. - Unlike C(include_role) variable exposure is not configurable, and will always be exposed.
''' '''

Loading…
Cancel
Save