* Moved the --list-hosts option that is common to both `ansible` and
`ansible-playbook` into utils/__init__.py (corrects a FIXME)
* Wrote new help text for the --list-hosts option that makes sense
for both of the commands that it applies to
* Changed the usage argument in `ansible-playbook` so that it is
setup in the base_parser method the same way that it is in
the `ansible` executable
* Updated the help text for several options to correct typos,
clarify meaning, improve readability, or fix grammatical errors.
In the case of `ansible-pull`, I changed the help text so that
it adheres to the same standards as the other executables.
The action doesn't actually change anything on a system, so setting
the status to changed is wrong. add_host is much like set_fact in that
regard.
Since changed is False by default, there is no need to explicity set
it, so just create an empty dict for result and add to it from there.
ansible.constants was calling expanduser (by way of shell_expand_path)
on the entire configured value for the library and *_plugins
configuration values, but these values have always been interpreted as
multiple directories separated by os.pathsep. Thus, if you supplied
multiple directories for one of these values, typically only the first
(at least on *nix) would have e.g. "~" expanded to HOME.
Now PluginLoader does expansion on each individual path in each of
these variables.
A host pattern of the form '!foo' by itself does not work, but
'all:!foo' does. If the first pattern is a negation, this commit
automatically prepends 'all'.
Signed-off-by: martin f. krafft <madduck@madduck.net>
name is used throughout Ansible, it's the "standard". This change
applies that standard to the add_host routine and updates the docs to
reflect that. Related to https://github.com/ansible/ansible/pull/3254
commit c36b66dc952dfff91043ecbca56cf3f1f8f00703
Merge: 240d7bf f4cf934
Author: Michael DeHaan <michael@ansibleworks.com>
Date: Tue Jun 18 13:04:51 2013 -0400
Merge branch 'unevaluated-vars' of git://github.com/lorin/ansible into lorin_undefined
Conflicts:
lib/ansible/runner/__init__.py
commit f4cf93436767f73b62a16067ab5e628830045896
Merge: 2531440 07a1365
Author: Lorin Hochstein <lorin@nimbisservices.com>
Date: Thu Jun 6 11:07:41 2013 -0400
Merge branch 'devel' into unevaluated-vars
commit 253144045cbafd7d72836f1017c62ac4ba623186
Author: Lorin Hochstein <lorin@nimbisservices.com>
Date: Thu Jun 6 11:06:37 2013 -0400
Fail template from file on undefined vars
If config option is set, raise an exception if templating from a
file and a variable is undefined.
commit aecb71d8b75257f0f3e11a9b176fc3737aecef8d
Author: Lorin Hochstein <lorin@nimbisservices.com>
Date: Wed Jun 5 17:12:12 2013 -0400
Add fail_on_undefined flag
Add a fail_on_undefined flag to the template and template_from_string methods.
If this flag is true, then re-raise the ninja2.excpetions.UndefinedError instead of
swallowing it.
commit cbb1808f0585f01536240aee05a1bfd06c4b4647
Merge: d4bbf49 41425fb
Author: Lorin Hochstein <lorin@nimbisservices.com>
Date: Wed Jun 5 16:14:12 2013 -0400
Merge branch 'devel' into unevaluated-vars
commit d4bbf492b0b63c789d66ab60d0ec634d100fca82
Author: Lorin Hochstein <lorin@nimbisservices.com>
Date: Mon Jun 3 19:46:13 2013 -0400
template: Raise UndefinedError exception
In template_from_string, raise an undefined error if it occurs.
Have the caller catch it and throw an AnsibleUndefinedVariable
commit c94780280515f1f3756fdc429b2b1e87b365e9b7
Merge: 8d919d6 be33bcf
Author: Lorin Hochstein <lorin@nimbisservices.com>
Date: Mon Jun 3 10:09:43 2013 -0400
Merge branch 'devel' into unevaluated-vars
commit 8d919d6c97b28a42f47ca7248c542695baf6175f
Merge: 0f68ad8 b8630d2
Author: Lorin Hochstein <lorin@nimbisservices.com>
Date: Thu May 30 16:27:48 2013 -0400
Merge branch 'devel' into unevaluated-vars
commit 0f68ad8193ac17488e339a258f8c63fdae399c26
Author: Lorin Hochstein <lorin@nimbisservices.com>
Date: Thu May 30 14:32:03 2013 -0400
Optionally fail task on undefined variables
This patch introduces a new configuration option called
error_on_undefined_vars, which defaults to false.
If this option is set to true, then a task which has unevaluated
variables in its arguments will fail instead of running. Output looks
like this:
TASK: [set rabbitmq password] *************************************************
fatal: [10.20.0.7] => Undefined variables: rabbitmq_user, rabbitmq_password
hardcoded lists in ansible code, just add WITH_ITEMS_USES_LIST in a
comment anywhere, and of course, support recieving params as list.
Signed-off-by: Brian Coca <briancoca+dev@gmail.com>
Previous commit c3659741 expanded sudo_user during task construction,
but this is too early as it does not pick up variables set during
the play.
This commit moves sudo_user expansion to the runner after variables
have been merged.
e.g. db[01:10:3]node-[01:10]
- to do this we split off at the first [...] set, getting the list
of hosts and then repeat until none left.
- also add an optional third parameter which contains the step. (Default: 1)
so range can be [01:10:2] -> 01 03 05 07 09
If someone has a " #" in a quoted var string, it
will interpret that as a comment and refuse to
load the inventory file due to an unbalanced
quote. Noisy failure > unexpected behavior.
Previously setting force=no caused copy to subversively
fail when target did not exist on remote host.
Caused by Runner._remote_md5 returning 1
when files don't exist, rather than 0.
PluginLoader._get_paths, as of 391fb98e, was only finding plug-ins that
were in a subdirectory of one of the basedirs (i.e. in a category
directory). For example, action_plugins/foo.py would never be loaded,
but action_plugins/bar/foo.py would work.
This makes it so that "uncategorized" plug-ins in the top level of a
directory such as action_plugins will be loaded, though plug-ins in a
"category" subdirectory will still be preferred. For example,
action_plugins/bar/foo.py would be preferred over action_plugins/foo.py.
If a variable was provided for an include, in either of these ways:
---
- hosts: all
tasks:
- include: included.yml param=www-data
- include: included.yml
vars:
param: www-data
and then that param was used as the value of sudo_user in the included
tasks:
---
- name: do something as a parameterized sudo_user
command: whoami
sudo: yes
sudo_user: $param
you would receive a "failed to parse: usage: sudo" error back and the
command would not execute.
This seemed to be due to a missing call to template.template somewhere,
because the final value being passed through ssh was still `$param`.
After some digging, the issue seems to instead have been a problem with
providing the wrong context to the template for expansion. Inside the
`Task` logic, it was passing `play.vars` as the context, where
`module_vars` seemed more appropriate. After replacing it, my test case
above ran without issue. There was a comment above suggesting that the
template call might be unnecessary, but removing it made the original
error return, since it is not getting escaped later down the line. I
removed the comment since it was inaccurate.
I tried to actually incorporate my test case above into the test suite
as a regression test, but was unable to figure out how to structure it.
The existing test infrastructure seemed to only be testing for correct
number of counts in things (ok vs. changed, etc.), without regard for
whether the content generated by the command is correct. If there is an
example of a test similar to this one (where I would want to check the
JSON generated to make sure sudo_user had been converted), please let me
know and I will be happy to submit an additional patch.
Excplicity set paramiko's logging level to WARNING.
By default it inherits ansible's DEBUG logging level (set in
callbacks.py) and fills the log file with useless debug messages.
Obviously it only applies if log_path is set in ansible.cfg
Added new parameter 'encrypt' with same semantics from that of
vars_prompt. When encryption is requested a random salt will be
generated and stored along the password in the form:
'<password> salt=<salt>'.
Also store passwords with an ending '\n' for easier looking at files
with console tools. File content was being already rstripped so this
is harmless.
From issue #2820, --start-at-task does not actually run tasks
unless --step is specified. This appears to be because skip_task
is being evaluated as True in PlayBook._run_task(). This patch
ensures skip_task is set to False in the callback.
