It turns out the Route53 API cares if the zone and record specified in the playbook are lower case or not when deleting a record. If you use a variable to name your servers and care about case, using that same proper case name will cause Route53 DNS delete requests to fail.
The change requested adds .lower() to the module.params.get for both zone and record when used in the underlying code.
Both zone and record are mandatory variables, and as such a more complicated implementation is not needed, as they must always be specified when using this module see lines 169 and 170 for the required state).
If you use lowercase names (or don't use a name variable and share it between a tag and DNS entries) then you will never see this issue.
Tested/Confirmed as an issue in Ansible 1.6.6 and above.
This small change corrects behavior when one uses an .rsync-filter file to exclude some paths from both being transferred and being deleted, so that these excluded paths can be handled separately with different tasks (e.g. in order to deploy the excluded paths independently from the rest paths and notify handlers appropriately). The problem with the double -FF option is that it excludes the .rsync-filter file from being transferred to the receiver. However, deletions are done on the side of the receiver, so it is absolutely necessary the .rsync-filter file to be transferred to the receiver, so that the receiver knows what files to delete and what not to delete.
Also moves the calculation of the destination file name until after
the slurp of the file contents, since the source as returned by slurp
may now be different, so we want to use that expanded path locally.
Fixes#8942
standards compliant return codes but return a verbose error message via
stdout. Limit the times when we invoke the heuristic to attempt to work
around this.
The example was showing how to use the `files` option to pass in a local file as an authorized public key for root. While this works, it's a bit sloppy, given that there's a specific option, `key_name` which will use one of your public keys on your rackspace account and add it as an authorized key for root. In our case, one of our admins didn't notice the `key_name` option because they scrolled straight to the example and saw the `files` strategy.
I propose that the example still shows `files`, but not using a root public key as an example, and instead also demonstrate the `key_name` option so that it's clear from the example how to get the initial root public key deployed.
This commit also makes the dest parameter optional, unless update=yes
(the default), since it is not required for queries without an update.
Fixes#8630
Also modifies the template action plugin to use this new param
when executing the file/copy modules for templating so that links
are preserved correctly.
Fixes#8998