When only looking at the failed state of the TaskResult, certain failures
cause the linear strategy to fail out sooner than it should and not execute
the always portion of blocks.
Fixes#24301
(cherry picked from commit f217dae938)
Fix converts commit_timeout to string as
Elementree.SubElement requires text as string.
Fixes#24611
Signed-off-by: Abhijeet Kasurde <akasurde@redhat.com>
(cherry picked from commit 2f955e7da8)
When checksums of local and remote files match, and when follow = True,
determine if remote destination is a symlink. If so, de-reference it and
pass the link target to the file module as 'dest'.
This change fixes an edge case in file copy behavior when:
- 'dest' is a symlink to some other file ('realdest')
- follow = True
- the checksums of the source file, 'src', and the symlink target, 'realdest',
match.
Because the checksums match, the copy module is skipped and the file module
is invoked directly with 'dest' = the symlink, and 'src' = the source of the
copy module, whether that source is present on the target machine or not.
When 'src' doesn't exist on the target machine, this leads to an error that
looks like this because it can't change the target of the symlink:
TASK [copy] ********************************************************************
fatal: [192.168.56.101]: FAILED! => {"changed": false, "checksum": "f572d396fae9206628714fb2ce00f72e94f2258f", "failed": true, "gid": 1000, "group": "ajdecon", "mode": "0777", "msg": "src file does not exist, use \"force=yes\" if you really want to create the link: /tmp/issue1568/dest_dir/source", "owner": "ajdecon", "path": "/tmp/issue1568/dest_dir/dest", "size": 8, "src": "source", "state": "link", "uid": 1000}
When the path 'src' *does* exist on the target machine, the file module makes
this the symlink "dest -> src" instead of "dest -> realdest"... even if the
checksum of 'src' on the target machine is different from the checksum of 'src'
on the machine where Ansible is running.
(cherry picked from commit 2f74f6738d)
For playbook base objects, when dumping attributes via dump_attrs() an
attribute like loop_control is a class. Using the default serialization
for these is slow and consumes a lot of memory. Since LoopControl is also
based on the Base class, we can use serialize() instead and save a lot of
resources.
This also adds a from_attrs() complimentary method to nicely turn the
dumped attrs back into proper field attributes.
Fixes#23579
(cherry picked from commit 78478e80ea)
In _process_pending_results (strategy/__init__.py), we were using the delegate_to
field directly from the original task, which was not being templated correctly.
As an alternate to #23599, this patch instead pulls the host name out of the delegated
vars passed back in the task result dictionary to avoid having to re-template things.
Fixes#23599Fixes#20508
(cherry picked from commit e5cd675b38)
* Fix for UnboundLocalError while accessing deprecations
in result
* Add Unit test
Fixes#24592
Signed-off-by: Abhijeet Kasurde <akasurde@redhat.com>
(cherry picked from commit 764b4b20ec)
With newer versions of ansible, module arguments are assumed to
be strings unless otherwise specified. Our 'facts' argument is
expected to be a dictionary, so tell ansible that.
Without this, the argument will arrive as a string and be written
to the facter file inside string quotes. Facter will produce the
following error:
undefined method `each' for #<String:0x000000016ee640>
This was originally fixed and found in the Ansible Puppet role which
is maintained by the OpenStack infrastructure team.
8d0f0bfd0a
Template can take a directory as the destination. When that's the case,
we need to diff between the source and the file inside of the directory.
That happened when the directory was specified with a trailing slash but
not when it was specified on its own. This change fixes that.
Fixes#24413
(cherry picked from commit 548cacdf6a)
the backport here 1f3f4cf702 forgot that
in ansible-2.3, the six library in ansible.module_utils is only 1.4.
1.4 doesn't have shlex_quote. Importing it from ansible.compat works
for ansible-2.3.
Previously, this module could throw the following error message:
NameError: global name 'current_roles_attrs' is not defined
The referencing key should also match the name of the column, which is
rolvaliduntil, not rol_valid_until
(cherry picked from commit c5adf08c40)
Fix adds check if app_key and api_key provided by
user is correct or not. If this combination is wrong
then fail with appropriate error message given by
Datadog server
Fixes https://github.com/ansible/ansible/issues/24325
Signed-off-by: Abhijeet Kasurde <akasurde@redhat.com>
(cherry picked from commit e342b281d8)
CVE-2017-7481
Lookup returns wrap the result in unsafe, however when used through the
standard templar engine, this does not result in the jinja2 environment being
marked as unsafe as a whole. This means the lookup result looses the unsafe
protection and may become simple unicode strings, which can result in bad
things being re-templated.
This also adds a global lookup param and cfg options for lookups to allow
unsafe returns, so users can force the previous (insecure) behavior.
(cherry picked from commit 72dfb1570d22ac519350a8c09e76c458789120ed)
Output of `yum check-update` can contain lines with long package names and long
repository label names, which will be broken into multiple lines, which need to
be sanitized. The solution to this has been fixed and refactored in 2.3 in form
of parse_check_update(), but it still contains subtle bug, which makes such
multi-lines invisible to later logic (such packages aren't included in
parse_check_update()) output. The problem is caused by using '\1' in re.sub(),
instead of proper r'\1', which literally puts unicode symbol \1 into resulting
output.
(cherry picked from commit c4ad0f86c7)
Use the default repr of AnsibleVaultEncryptedUnicode.data instead
of a custom one, since jinja templating ends up using the repr()
results.
Fixes#23846, #24175
(cherry picked from commit 7fe2064162)
ssh-keyscan isn't very verbose about errors. Give the user whatever
information we have available even if it isn't much. At least they will
know how we were running ssh-keyscan and why there's an error now.
Fixes#19440
(cherry picked from commit 4bf8071889)
James Cammarata