Changed=true now reported on new volume.
Only detach volume when instance is specified as 'None' or '' rather than whenever instance is not specified at all
Fix regression caused by 6b27cdc where by no volume is created if id or Name is not supplied
Remove unnecessary empty aliases
Corrected example to use acceptable parameter for ions
Added exception handling to get_all_instances call
Moved the attachment state validation code to attach_volume function rather than create_volume function
Refactored attach_volume and detach_volume so that changed state can be passed back to call
Created get_volume_info function so that state=present and state=list can return the same data. Also added instance_id as a returned value in attachment_set dict
Updated aws connection method so that boto profile can be used
When pulling an image using Docker 1.8, it seems the output
JSON stream has an empty dict at the very end. This causes
ansible to fail when pulling an image, as it's expecting a
status message in that dict which it uses to determine whether
it had to download the image or not. As a bit of an ugly hack
for that which remains backward compatible, try the last item
in the stream, and if it's an empty dict, take the last-but-one
item instead.
The strip() is needed as the exact value appears to be '{}/r/n';
we could just match that, but it seems like the kind of thing
where maybe it'd happen to just be '{}/n' or '{}' or something
in some cases, so let's just use strip() in case.
A recent change [1] in docker between v1.8.2 and v1.8.3 changed what
is returned in the json when inspecting an image. Five variables which
could have been expected before will now be omited when empty. Only
one of those variables is being addressed in the docker, ExposedPorts.
Unfortunately there was also no API version change on this so this
can't be easily corrected with pinning the API to the older version.
This does a get() which will return None if the variable is not in the
dict formed from the json that was returned. Everything else works the
same way.
[1] 9098628b29
Without this, «ec2: state=stopped instance_ids=…» would fail with a
traceback like this:
if inst.get_attribute('sourceDestCheck')['sourceDestCheck'] != source_dest_check:
NameError: global name 'source_dest_check' is not defined
Detached head detection seems to have broken somewhere a long the way
because git decided to change how that situation looks when doing a 'git
branch -a' which is performed by get_branches().
This is how git 1.7.1 displays this situation (which works):
shell> git branch -a
* (no branch)
master
This is the output from git 1.8.3.1 (which does not work):
shell> git branch -a
* (detached from e132711)
master
It looks like this same wording is used in the most recent version of
git (2.6.1 as of writing this).
Both `source_dest_check` and `termination_protection` variables are not
available within the scope of the startstopec2 instance method. This just
pulls them from module.params.
With shade > 0.13.0, networks can be created that are externally
accessible. This adds a parameter for that.
Also, add RETURN documentation and 'if __name__' check around call
to main().
I think in this commit 720aeffca2
There was bug introduced where the ElastiCacheManager init method has
a number of positional arguments like so.
```py
def __init__(self, module, name, engine, cache_engine_version, node_type,
num_nodes, cache_port, parameter_group, cache_subnet_group,
cache_security_groups, security_group_ids, zone, wait,
hard_modify, region, **aws_connect_kwargs):
```
But then later in the code the positional arguments are passed in
like this.
```py
elasticache_manager = ElastiCacheManager(module, name, engine,
cache_engine_version, node_type,
num_nodes, cache_port,
cache_subnet_group,
cache_security_groups,
security_group_ids, parameter_group, zone, wait,
hard_modify, region, **aws_connect_kwargs)
```
If you count, you can see that cache_subnet_group, is being passed in
where the manager expects to see parameter_group.
There can be instances during an Ansible play where the list of subnets
currently available from OpenStack is required. This update provides
subnet list functionality as a new os_subnets_facts module.
There can be instances during an Ansible play where the list of networks
currently available from OpenStack is required. This update provides
network list functionality as a new os_networks_facts module.
An attempt to make clear how privilege escalation works with respect to the src/source host and dest/destination host. One existing note was incorporated into three new ones, iterating each.
It is not documented in [the Ansible doc page][1] nor
[the BSD setfacl man entry][2] (which means it might not be compatible
with BSD) so removing it does not break the API.
On the other hand, it does not conform with POSIX 1003.1e DRAFT
STANDARD 17 according to the [Linux setfacl man entry][3] so safer to
remove.
Finally, the most important reason: in non POSIX 1003.e mode, only ACL
entries without the permissions field are accepted, so having an
optional field here is very much error-prone.
[1]: http://docs.ansible.com/ansible/acl_module.html
[2]: http://www.freebsd.org/cgi/man.cgi?format=html&query=setfacl(1)
[3]: http://linuxcommand.org/man_pages/setfacl1.html
This patch allows the hostname module to detect and set the hostname for a
Kali Linux 2.0 installation. Without this patch, the hostname module raises
the following error
hostname module cannot be used on platform Linux (Kali)
Kali is based off of Debian.
Fixes https://github.com/ansible/ansible/issues/11768
Test plan:
- (in a Vagrant VM) created a user 'bob' with no ssh key
- ran the following playbook in check mode:
---
- hosts: trusty
tasks:
- user: name=bob state=present generate_ssh_key=yes
- saw that ansible-playbook reported "changes=1"
- saw that /home/bob/.ssh was still absent
- ran the playbook for real
- saw that /home/bob/.ssh was created
- ran the playbook in check mode again
- saw that ansible-playbook reported no changes
- tried a variation with a different username for a user that didn't
exist: ansible-playbook --check worked correctly (no errors, reported
"changed")
PR #1651 fixed issue #1515 but the requirement for path to be defined is unecessarily strict. If the user has previously been created a path isn't necessary.
This patch properly fixes bug 1226 without introducing a breaking
change to idempotency which was introduced in PR #1358
We can properly assign permissions to databases with a '.' in the name
of the database as well as assign priviliges to all databases as
specified with '*'
While this change doesn't break the creation, it does break
idempotency. This change will convert '*.*' to '`*`.*' which is
functionally the same, however when the user_mod() function looks up
the current privileges with privileges_get() it will read '*.*'
Since '*.*' != '`*`.*' it will go through the process of updating the
privleges always resulting in a 'changed' result.
This reverts commit db9ab9b262.
