I hastily did a copy/paste of the `async` example and it took me
a while to understand that `async` specified a maximum runtime in seconds.
The docs are actually mostly clear on this, but I made this PR while
reading the code.
This also fixes the spelling of "asynchronously".
* Make the module idempotent
* pep8 fixes.
* Made required changes for overwrite_value for idempotency.
* Fix missing error definition
* Add in missing documentation variable.
* Use arg_spec type for comparisons on default and choices
* Further improve type casting
* Make sure to capture output in more places
* Individually report invalid choices
* Update ignore.txt after resolving merge conflicts
* Make it less likely that we have to identify all the modules during
a playbook run. PluginLoader is optimized to look for modules one
directory at a time. If we find a module before we've examined all
the directories we never have to touch the other directories.
Reordering this conditional makes it so tasks which don't have
a module file will not force us to examine all the module directories
before moving on to other sources of task actions.
* Change several variables we consult to see if a task is in a certain
category from lists/tuples to frozensets. These are static lists
which we only do containment tests on so frozensets should be faster
Fixes#37208
If check_mode is enabled instead of committing th config need to
discard all the chnages to cnadidate db
In case of cli to discard changes issue `rollback 0` command
and for netconf execute `discard-changes` rpc call
The message text used to check stderr for a warning about
groupinstall in order to determine if a change occurred is specific
to the version of yum that is in RHEL7 and newer. This change simply
removes a couple words off the end in order to only use text found
in the warning message in older versions of yum.
Fixes#35982
Signed-off-by: Adam Miller <admiller@redhat.com>
This patch fixes up some English typos in the yaml inventory
plugin documentation.
* s/specifically/specific
* s/as/as an
Signed-off-by: Eric Brown <browne@vmware.com>
If a repo with `repo_gpgcheck=1` is added and the repo GPG key was never
accepted, quering this repo would throw an error `repomd.xml signature
could not be verified` and the module would fail. If that happens now
`yum -y makecache` will be run which will fetch the new repo data and
accept the repo GPG key.
* Add tests using a variable in tasks_from field
Related to #32503
* Do not test using hostvars with import_role
hostvars cannot be used with import_role — use include_role instead
* template: Add integration tests for `lstrip_blocks'
Signed-off-by: Alex Tsitsimpis <alextsi@arrikto.com>
* template: Fix passing `trim_blocks' inline
Fix passing `trim_blocks' option to the template module as inline
argument. Previously passing the `trim_blocks' option inline instead of
using the YAML dictionary format resulted in it always being set to
`True', even if `trim_blocks=False' was used.
Signed-off-by: Alex Tsitsimpis <alextsi@arrikto.com>
* template: Add option to `lstrip_blocks'
Add option to set `lstrip_blocks' when using the template module to
render Jinja templates. The Jinja documentation suggests that
`trim_blocks' and `lstrip_blocks' is a great combination and the
template module already provides an option for `trim_blocks'.
Note that although `trim_blocks' in Ansible is enabled by default since
version 2.4, in order to avoid breaking things keep `lstrip_blocks'
disabled by default. Maybe in a future version it could be enabled by
default.
This seems to address issue #10725 in a more appropriate way than the
suggested.
Signed-off-by: Alex Tsitsimpis <alextsi@arrikto.com>
* template: Add integration tests for `trim_blocks'
Signed-off-by: Alex Tsitsimpis <alextsi@arrikto.com>
* template: Check Jinja2 support for `lstrip_blocks'
Since the `lstrip_blocks' option was added in Jinja2 version 2.7, raise
an exception when `lstrip_blocks' is set but Jinja2 does not support it.
Check support for `lstrip_blocks' option by checking `jinja2.defaults'
for `LSTRIP_BLOCKS' and do not use `jinja2.__version__' because the
latter is set to `unknown' in some cases, perhaps due to bug in
`pkg_resources' in Python 2.6.6.
Also update option description to state that Jinja2 version >=2.7 is
required.
Signed-off-by: Alex Tsitsimpis <alextsi@arrikto.com>
