Allow security tokens and profiles to be used as arguments
to the 'common' ec2 modules
Mostly refactoring to provide two new methods,
`get_aws_connection_info`, which results in a dict that can be
passed through to the boto `connect_to_region` calls, and
`connect_to_aws` that can pass that dict through to the
`connect_to_region` method of the appropriate module.
Tidied up some variable names
Works around boto/boto#2100
profiles don't work with boto < 2.24, but this detects for that
and fails with an appropriate message. It is designed to work
if profile is not passed but boto < 2.24 is installed.
Modifications to allow empty aws auth variables to be passed
(this is useful if wanting to have the keys as an optional
parameter in ec2 calls - if set, use this value, if not set,
use boto config or env variables)
Reworked validate_certs improvements to work with refactoring
Added documentation for profile and security_token to affected modules
In order to simplify the workflow with the GCE modules, it's now
possible to add the parameters and project name as arguments to the
various GCE modules.
The inventory plugin also returns the IP of the host in
`ansible_ssh_host` so that you don't have to specify IPs into the
inventory file.
Some update to the documentation are also added.
Closes#5583.
failed: [127.0.0.1] => {"failed": true, "parsed": false}
invalid output was: Traceback (most recent call last):
File "/tmp/ansible-tmp-1393950384.39-102240090845592/nova_compute", line 1328, in <module>
main()
File "/tmp/ansible-tmp-1393950384.39-102240090845592/nova_compute", line 241, in main
except exc.Unauthorized, e:
NameError: global name 'exc' is not defined
When there is an Openstack instance that has a name that's a partial match
for module.params['name'], but a server with name module.params['name']
doesn't yet exist, this module would fail with a list index out of bounds
error. This fixes that by filtering by exact name and only then getting the
server from the list if the list is still not empty.
The newest version of OpenSSH supports a new, wonderful key type. authorized_key incorrectly discards pubkeys of this type as busted because it doesn't recognize type signature.
If no group was specified, but a group by the same name as the user
exists, an error was raised in the situation where USERGROUPS_ENAB is
enabled in /etc/login.defs (which is the case for almost every major
linux distro). In this case, the user will be put in group 100 (which
is usually the "users" group on those same distros). This is currently
only done in the base class, as the issue may not exist on other
platforms like AIX or the BSDs.
Fixes#6210