* Retain vault password as bytes in 2.2
Prior to 2.2.1, the vault password was read in as byes and then remained
bytes all the way through the code. A bug existed where bytes and text
were mixed, leading to a traceback with non-ascii passwords. In devel,
this was fixed by changing the read in password to text type to match
with our overall strategy of converting at the borders. This was
backported to stable-2.2 for the 2.2.1 release.
On reflection, this should not have been backported as it causes
passwords which were originally non-utf-8 to become utf-8. People will
then have their working 2.2.x vault files become in-accessible.
this commit pipes bytes all the way through the system for vault
password. That way if a password is read in as a non-utf-8 character
sequence, it will continue to work in 2.2.2+. This change is only for
the 2.2 branch, not for 2.3 and beyond.
Why not everywhere? The reason is that non-utf-8 passwords will cause
problems when vault files are shared between systems or users. If the
password is read from the prompt and one user/machine has a latin1
encoded locale while a second one has utf-8, the non-ascii password
typed in won't match between machines. Deal with this by making sure
that when we encrypt the data, we always use valid utf-8.
Fixes#20398
(cherry picked from commit 5dcce0666a)
* description is only required when group state is present
also note that AWS requires a non-empty description when creating a security group
* clarify description requirement
One way to trigger this is having this snippet in meta/main.yml:
dependencies:
- role: foo
when: "use_foo == True"
It shouldn't show a warning but since we assume that 'foo' is the old
style format, it always show one. So we should verify the
style before calling role_spec_parse.
* virt.py: autostart VM attribute
autostart is now an idempotent VM attribute instead of a non idempotent forced autostart attribute set to True
* Make shippable happy
* Missing version added
* Fix some points
* Autostart default is now None
* Ident fix
1. Check less aggressively for resources that take a long time to return
(some resources can take an hour or more).
2. Handle throttling when checking for resources, and back off quickly
when it occurs.
* Add user_data_path parameter to ec2_lc module
* Improve user_data_path parameter documentation
- Specify mutual exclusivity
- Specify `version_added`
- Change module parameter type to `path`
* Use correct comparison for user_data result
* Include traceback on error and use with block
* Only hide user data if provided in file
* Use packaging.version.Version instead of LooseVersion for better support of prerelease tags (eg, 0.30.0 > 0.30.0rc6)
* Add explicit check/error for msrestazure package
If a key has expired it will not be added by this module, so check for "expired" in the list of keys.
Example output with expired key:
pub 1024D/5072E1F5 2003-02-03 [expired: 2017-02-16]
uid MySQL Release Engineering <mysql-build@oss.oracle.com>
ensure_tags fails if `tags` is None rather than an empty
dict. Ensure that not passing `tags` parameter is equivalent
to passing an empty dict.
Fixes#21778
If the host .bashrc holds a var named HOSTNAME, the container
where the lxc_container module will attach to will inherit from
this var, potentially breaking some applications (like rabbitmqctl)
due to an incorrect $HOSTNAME reported in the container.
* Add flag to Docker pull_image to know when the image is already latest
Whenever the flag pull is set to 'yes' the resource is always defined
as 'changed'. That is not true in case the image is already at the
latest version.
Related to ansible/ansible#19549
* Docker pull_image does not change status if the image is latest
This commit also adds a new test script (ansible-var-precedence-check.py in code-smell/)
to provide us with another line of defense against precedence bugs going forward.
The precedence docs state that the INI vars have a lower precedence than group/host
vars files for inventory and playbooks, however that has not been the case since 2.0
was released. This change fixes that in one way, though not exactly as the docs say.
The rules are:
1) INI/script < inventory dir < playbook dir
2) "all" group vars < other group_vars < host_vars
So the new order will be (from the test script mentioned above):
8. pb_host_vars_file - var in playbook/host_vars/host
9. ini_host_vars_file - var in inventory/host_vars/host
10. ini_host - host var inside the ini
11. pb_group_vars_file_child - var in playbook/group_vars/child
12. ini_group_vars_file_child - var in inventory/group_vars/child
13. pb_group_vars_file_parent - var in playbook/group_vars/parent
14. ini_group_vars_file_parent - var in inventory/group_vars/parent
15. pb_group_vars_file_all - var in playbook/group_vars/all
16. ini_group_vars_file_all - var in inventory/group_vars/all
17. ini_child - child group var inside the ini
18. ini_parent - parent group var inside the ini
19. ini_all - all group var inside the ini
Fixes#21845
