This fix ensures a proper error is shown when a group_vars files cannot
be parsed correctly. Without this patch you get:
```
[dag@moria ansible.testing]$ ansible-playbook test132.yml
ERROR! Unexpected Exception: dictionary update sequence element #0 has length 1; 2 is required
to see the full traceback, use -vvv
```
With this patch you get:
```
[dag@moria ansible.testing]$ ansible-playbook test132.yml
ERROR! Problem parsing file '/home/dag/home-made/ansible.testing/group_vars/test135': line 1, column 1
```
This fixes#18843
Previously, the Conditional class did a simple check when an
AnsibleUndefinedVariable error was raised to see if certain strings were
present. This patch tries to be smarter by evaluating the variable contained
in the error string and compared to the defined/not defined conditionals in
the conditional string.
This also modifies the UndefinedError message from HostVars slightly to
match the format returned jinja2 in general, making it easier to match the
error message in the Conditional code.
Fixes#18514
Currently, if the host specified in delegate_to for a task is null,
Ansible will crash with a stack trace. Add a check for this state
and handle the error appropriately.
* refactor ignore_limits_and_restrictions
into ignore_limits and ignore_limitations
* add ansible_play_hosts_all
* update docs re ansible_play_hosts_all
* only use play.hosts when is has a value
* replace ansible_play_hosts with ansible_play_hosts_all
* remove unnecessary var
When using hostvars to get extra connection-specific vars for connection
plugins, use this raw lookup to avoid prematurely templating all of the
hostvar data (triggering unnecessary lookups).
Fixes#17024
We couldn't copy to_unicode, to_bytes, to_str into module_utils because
of licensing. So once created it we had two sets of functions that did
the same things but had different implementations. To remedy that, this
change removes the ansible.utils.unicode versions of those functions.
for `VariableManager._get_magic_variables()`.
This saves a lot of time re-iterating the nearly always constant global
list of groups and their members.
Generate once and cache, and invalidate cache in case `add_host:` or
`group_by:` are used.
* attempt #11 to role_include
* fixes from jimi-c
* do not override load_data, move all to load
* removed debugging
* implemented tasks_from parameter, must break cache
* fixed issue with cache and tasks_from
* make resolution of from_tasks prioritize literal
* avoid role dependency dedupe when include_role
* fixed role deps and handlers are now loaded
* simplified code, enabled k=v parsing
used example from jimi-c
* load role defaults for task when include_role
* fixed issue with from_Tasks overriding all subdirs
* corrected priority order of main candidates
* made tasks_from a more generic interface to roles
* fix block inheritance and handler order
* allow vars: clause into included role
* pull vars already processed vs from raw data
* fix from jimi-c blocks i broke
* added back append for dynamic includes
* only allow for basename in from parameter
* fix for docs when no default
* fixed notes
* added include_role to changelog
The flag new_pb_basedir is not being utilized in Inventory._get_hostgroup_vars,
leading to the situation where an inventory with no playbook basedir set will
read host/group vars from the $CWD, regardless of the inventory and/or playbook
relative location. This patch corrects that by not using the playbook basedir
if it is unset (None).
This patch also corrects a bug in which the VariableManager would accumulate
host/group vars files, which could lead to incorrect vars files being used when
playbooks are run from different directories containing their own group/host vars
directories.
Fixes#16953
* Revert "There can be only one localhost"
This reverts commit 5f1bbb4fcd.
this broke several usages of localhost, see #16882, #16898 and #16886
* ensure there is only 1 localhost
fixes#16886, #16882 and #16898
- make sure localhost exists before returning it
- optimzed host caching
- ensure we always return a host object
This bug was introduced in 3ced6d3, where getting vars from a role
did not follow the dep chain. This was originally hidden by the fact
that we got vars twice (from the block and from the roles directly).
Fixes#16729
Also updates doc on variable precedence, as it was incorrect for the
order of play vars/vars_prompt/vars_files in relation to set_fact and
registered variables.
Fixes#14702Fixes#14826
* In the VariableManager, we were not properly tracking if a file
had already been loaded, so we continuously append data to the end
of the list there for host and group vars, meaning large sets of data
are duplicated multiple times
* In the inventory, we were merging the host/group vars with the vars
local to the host needlessly, as the VariableManager already handles that.
This leads to needless duplication of the data and makes combining the
vars in VariableManager take even longer.
Child blocks (whether nested or via includes) don't get a copy of the
dependency chain, so the above method should be used to ensure the block
looks at its parents dep chain.
Fixes#15996
In VariableManager, we fetch the params specifically in the next step,
so including them in the prior step is unnecessary and could lead to things
being overridden in an improper order.
In Block, we should not be getting the params for the role as they are
included earlier via the VariableManager.
Fixes#14411
* Make role param resolution follow the role dependency chain, rather
than using all roles within the play
* Also move params to be merged in after role vars in general, to match
our variable precedence rules
* Changes to the way var lookup is done in role helper methods for
get_vars(), get_inherited_vars(), and get_role_params() to make the
above possible without trampling on previously merged vars
Fixes#14472Fixes#14475
Looks like someone forgot to create an instance of undefined here- we were returning the undefined type object, which broke all the undefined checks.
Added an integration test around add_host that will catch this (separate PR to follow)
Also displays a warning now, because users should not be using that variable
name as it causes a collision with the internal variable of the same name.
The first call to persisting facts would work due to the assignment of a
MutableMapping calling __setitem__ but subsequent module fact data would
not be propogated to the fact cache plugins because update() doesn't
invoke __setitem__. This changes the behavior a little bit and ensures
set() is called on cache plugins.
Also does some reorganization/cleanup on the magic vars/delegated
variable generation portions of VariableManager to make the above
possible.
Fixes#12633
James Cammarata
Matt Clay
Brian Coca
Computest
Dag Wieers
Brian Coca
stephane
cinerama70
j0hnsmith
nvigot
Toshio Kuratomi
Tobias Wolf
Matthew Stoltenberg
nitzmahone
Strahinja Kustudić
Brian Coca
Yannig Perré
Toshio Kuratomi
Marius Gedminas
Ben Keith
Matthew Jones