Uses the new get_aws_connection_info
and connect_to_aws common methods to reuse code
Now complains if region is not set in one of the
three possible methods
Also moved over to common documentation code so
this is actually based on #6913
When disabled, the boto connection will be instantiated without validating
the SSL certificate from the target endpoint. This allows the modules to connect
to Eucalyptus instances running with self-signed certs without errors.
Fixes#3978
The `ec2_ami`, `ec2_elb`, `ec2_tag`, `ec2_vpc`, `route53`, and `s3` modules
all canonicalize the AWS access and secret key params as
`aws_access_key` and `aws_secret_key`. However, following the fixes for #4540,
those modules now use `get_ec2_creds` from `lib/ansible/module_utils/ec2.py`,
which requires access/secret key params to be canonicalized as
`ec2_access_key` and `ec2_secret_key`. As a result, AWS credentials passed
to those six modules as parameters are ignored (they instead always use
the AWS credentials specified via environment variables, or nothing).
So this change fixes those six modules to canonicalize the
AWS access and secret key params as `ec2_access_key` and `ec2_secret_key`,
allowing them to again accept AWS credentials passed via module params.
Boto blindly assumes the us-east-1 region if you don't hardcode a
region in it's config, so you could end up attempting to modify ELB's
in one region from a totally different region. If a region isn't
specified then default to the region that the module is being run
within rather than the default us-east-1 region since it's a pretty
safe assumption that you intend to work on the ELB's within your
current region.
Also throw an error if a specified ELB instance doesn't exist. The old
behavior would be to silently succeed with changed=false, so if you had
so much as a typo in the name of your ELB (or were in the wrong region
like my initial testing) you wouldn't get a clear indication that a
problem had occurred.
This module handles AWS EC2 ELB registration.
* De-registration requires the instance id which can be looked up using
the ec2_facts module.
* Registration requires both the instance id and the elbs that the
instance belongs to.
De-registration will return an ec2_elb fact that can be used for
registration in post_tasks.
