1. The test did "name: '{{hostnames}}.{{item}}'" inside a with_sequence
loop, which didn't do what was intended: it expanded hostnames into
an array, appended ".1", and set name to the resulting string. This
can be converted to a simple with_items loop.
2. Some of the entries in hostnames contained punctuation characters,
which I see no reason to support in inventory hostnames anyway.
3. Once the add_host failures are fixed, the playbook later fails when
the unicode hostnames are interpolated into debug output in ssh.py
due to an encoding error. This is only one of the many places that
may fail when using unicode inventory hostnames; we work around it
by providing an ansible_ssh_host setting.
Labels must start with an alphanumeric character, may contain
alphanumeric characters or hyphens, but must not end with a hyphen.
We enforce those rules, but allow underscores wherever hyphens are
accepted, and allow alphanumeric ranges anywhere.
We relax the definition of "alphanumeric" to include Unicode characters
even though such inventory hostnames cannot be used in practice unless
an ansible_ssh_host is set for each of them.
We still don't enforce length restrictions—the fact that we have to
accept ranges makes it more complex, and it doesn't seem especially
worthwhile.
This adds a parse_address(pattern) utility function that returns
(host,port), and uses it wherever where we accept IPv4 and IPv6
addresses and hostnames (or host patterns): the inventory parser
the the add_host action plugin.
It also introduces a more extensive set of unit tests that supersedes
the old add_host unit tests (which didn't actually test add_host, but
only the parsing function).
There was code to support set literals (on Python 2.7 and newer), but it
was buggy: SAFE_NODES.union() doesn't modify SAFE_NODES in place,
instead it returns a new set object that is then silently discarded.
I added a unit test and fixed the code. I also changed the version
check to use sys.version_tuple instead of a string comparison, for
consistency with the subsequent Python 3.4 version check that I added in
the previous commit.
The full error was
======================================================================
ERROR: test_task_executor_execute (units.executor.test_task_executor.TestTaskExecutor)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/mg/src/ansible/test/units/executor/test_task_executor.py", line 252, in test_task_executor_execute
mock_action.run.return_value = dict(ansible_facts=dict())
File "/home/mg/src/ansible/lib/ansible/executor/task_executor.py", line 317, in _execute
if self._task.async > 0:
TypeError: unorderable types: MagicMock() > int()
----------------------------------------------------------------------
Experiments show that Python 2 MagicMock() > 0 is true, so I'm setting
the async property on mock_task to 1. (If I set it to 0, the test fails
anyway.)
Required some rewiring in inventory code to make sure we're using
the DataLoader class for some data file operations, which makes mocking
them much easier.
Also identified two corner cases not currently handled by the code, related
to inventory variable sources and which one "wins". Also noticed we weren't
properly merging variables from multiple group/host_var file locations
(inventory directory vs. playbook directory locations) so fixed as well.
Replace .iteritems() with six.iteritems() everywhere except in
module_utils (because there's no 'six' on the remote host). And except
in lib/ansible/galaxy/data/metadata_template.j2, because I'm not sure
six is available there.
ansible is passing unicode arond internally so we should test the same
data.
* Add a zero length test for _count_newlines and fix the zero newlines
test to have no newlines.
`assert (condition, message)` gets parsed by Python as `assert
a_two_tuple`, and a 2-element tuple is never False.
Discovered by compileall on Python 3.4, which emits a SyntaxWarning for
this common mistake.
Note that this test was broken in devel because it was really just
duplicating the AES256 test because setting v.cipher_name to 'AES'
no longer selected AES after it was de-write-whitelisted.
Now that we've removed the VaultAES encryption code, we embed static
output from an earlier version and test that we can decrypt it.
* Add exception handling when running PowerShell modules to provide exception message and stack trace.
* Enable strict mode for all PowerShell modules and internal commands.
* Update common PowerShell code to fix strict mode errors.
* Fix an issue with Set-Attr where it would not replace an existing property if already set.
* Add tests for exception handling using modified win_ping modules.
This change is similar to https://github.com/ansible/ansible/pull/10465
It extends the logic there to also support none types. Right now if you have
a '!!null' in yaml, and that var gets passed around, it will get converted to
a string.
eg. defaults/main.yml
```
ENABLE_AWESOME_FEATURE: !!null # Yaml Null
OTHER_CONFIG:
secret1: "so_secret"
secret2: "even_more_secret"
CONFIG:
hostname: "some_hostname"
features:
awesame_feature: "{{ ENABLE_AWESOME_FEATURE}}"
secrets: "{{ OTHER_CONFIG }}"
```
If you output `CONFIG` to json or yaml, the feature flag would get represented in the output
as a string instead of as a null, but secrets would get represented as a dictionary. This is
a mis-match in behaviour where some "types" are retained and others are not. This change
should fix the issue.
I also updated the template test to test for this and made the changes to v2.
Added a changelog entry specifically for the change from empty string to null as the default.
Made the null representation configurable.
It still defaults to the python NoneType but can be overriden to be an emptystring by updating
the DEFAULT_NULL_REPRESENTATION config.
- Add support for inserting module args into PowerShell modules. Fixes#11661.
- Support Windows paths containing spaces. Applies changes from #10727 to v2. Fixes#9999. Should also fixansible/ansible-modules-core#944 and ansible/ansible-modules-core#1007.
- Change how execution policy is set for running remote scripts. Applies changes from #11092 to v2. Also fixesansible/ansible-modules-core#1776.
- Use codepage 65001 (UTF-8) for WinRM connection instead of default (CP437), convert command to UTF-8 and results from UTF-8. Replaces changes from #10024. Fixes#11198.
- Close WinRM connection when task completes.
- Use win_stat, win_file and win_copy modules instead of stat, file and copy when called from within other action plugins (only when using WinRM+PowerShell).
- Unquote Windows path arguments before passing to win_stat, win_file, win_copy and slurp modules (only when using WinRM/PowerShell).
- Check for win_ping module to determine if core modules are missing (only when using WinRM/PowerShell).
- Add stdout_lines to result from running low level commands (so stdout_lines is available when using raw/script).
- Update copy action plugin to use shell functions for joining paths and checking for trailing slash.
- Update fetch action plugin to unquote source path when using Windows paths.
- Add win_copy and win_template action plugins that inherit from copy and template.
- Support running .bat and .cmd scripts using default system encoding instead of UTF-8.
- Always send PowerShell commands as base64-encoded blobs to allow for running simple PowerShell commands via raw.
- Support running modules on Windows with interpreters other than PowerShell.
- Update integration tests to support above changes and test unicode fixes.
- Add test for win_user error from ansible/ansible-modules-core#1241 (fixed by ansible/ansible-modules-core#1774).
- Add test for additional win_stat output values (implemented by ansible/ansible-modules-core#1473).
- Add test for OS architecture and name from setup.ps1 (implemented by ansible/ansible-modules-core#1100).
All WinRM integration tests pass for me with these changes.
Also making PlayContext a child class of the Playbook Base class,
which gives it access to all of the FieldAttribute code to ensure
field values are correctly typed after post_validation
Fixes#11381
* Perhaps the only precedence change, in 2.0+ variables from set_fact
will not override params to an include file, as params are expected
to be more specific than host-based variables.
* Uncommented long-form include example.
In issue #10073 a misbehaviour in literal handling for inline lookup
arguments that can cause unexpected behaviur was reported. This
integration testcase reproduce the problem.
After applying pull request #10991 the issue is fixed and the test
passes.
Signed-off-by: Jan Losinski <losinski@wh2.tu-dresden.de>
Before this change if a variable was of type int or bool and the variable was referenced
by another variable, the type would change to string.
eg. defaults/main.yml
```
PORT: 4567
OTHER_CONFIG:
secret1: "so_secret"
secret2: "even_more_secret"
CONFIG:
hostname: "some_hostname"
port: "{{ PORT }}"
secrets: "{{ OTHER_CONFIG }}"
```
If you output `CONFIG` to json or yaml, the port would get represented in the output as a
string instead of as a number, but secrets would get represented as a dictionary. This is
a mis-match in behaviour where some "types" are retained and others are not. This change
should fix the issue.
Update template test to also test var retainment.
Make the template changes in v2.
Update to only short-circuit for booleans and numbers.
Added an entry to the changelog.
The --force-handlers command line argument was not correctly running
handlers on hosts which had tasks that later failed. This corrects that,
and also allows you to specify force_handlers in ansible.cfg or in a
play.