If `get_all_instances` returns multiple reservations, the old wait loop only
dealt with the first reservation. Thus, the wait loop may end before all
instances get to be running/stopped.
Also clean up the code a little.
`decoded_name` was created twice, each from `rset.name`
So, the second call to `.replace(r'\100', '@')` overwrites decoded_name, discarding the result of the call to `.replace(r'\052', '*')`
I had a problem with wildcard domains that was fixed by this patch.
Upon a second run, the default egress rule will be removed when a
vpc is specified but no other egress rules were set. This patch
corrects that behavior by removing the default egress rule from the
list of unmatched outbound rules.
Fixes#7309
* the current state of the ELB was not reflected properly when checking
the status after a change was made.
* invalid zones caused a traceback when enabling/disabling zones
ec2_snapshot got missed when moving to a common argument spec.
It could already make use of the capabilities (as it uses
ec2_connect) and the documentation suggested it supported the
common argument spec (thanks to the documentation fragment work)
so it was just a matter of fixing the argument spec.
Removed unnecessary documentation for profile and security_token
that is covered by documentation fragment
Also removed spurious documentation flags (default: null, aliases: [])
which aren't needed.
The JSON the Docker API returns includes the container's ENTRYPOINT value (if it has one) with the 'Command' value. So instead of checking if `container['Command'] == module.params['command']`, we just check that `container['Command'].endswith(module.params['command'])` so the entrypoint won't affect a container being properly classified as matching the module params or not.
Also I refactored a super-long `if` statement into some temporary variables - I did it to help me figure out what was going wrong, and then it makes the code more readable so I kept it.
As part of being updated for the 1.10 API, a couple of parameters were passed to the docker.client.start() command that it doesn't accept. This caused the module to error out if it tried to start any Docker containers. This removes those parameters so the module works again.
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
Created common module doc fragment, and applied to all
modules that use ec2_connect or connect_to_aws as
they definitely share the common doc fragments
* Catch issues with invalid regions
* Ensure we send string only data as meta values in the rax module
* Add public_key/lookup example for rax_keypair
* Clean up import statements
While the [boto docs](https://github.com/boto/boto/blob/develop/boto/rds/__init__.py#L253) make it seem like the default value of `port` is changed depending on the engine chosen, AFAICT from looking at the code the default value is never changed from 3306.
I think the docs are intended to be read as "the default value used by <engine> is <port> so you should change `port` to that value".
If you don't specify the port value and chose the database engine as PostgreSQL you'll end up with a PostgreSQL instance running on port 3306.
Without the `subnet` parameter supplied there's an error `msg: Parameter vpc_security_groups invalid for create command`. (This might be a bug?)
If the VPC security group name rather than ID is supplied there's an error: `msg: Invalid security group , groupId= <some group name>, groupName=.` (Accepting a group name might be a feature enhancement.)
In my case I set the subnet as `default` and used `register` to get the result of the security group creation section and just referred to its `group_id` property.
Add extra_create_args and extra_client_args to rax module to support passing
advanced configuration options to client instantiation and server create calls.
When a group is created, an egress_rule ALLOW ALL to 0.0.0.0/0 is added
automatically but it's not reflected in the object returned by the AWS API
call. After creation we re-read the group for getting an updated object.
Suppose a pair of groups, A and B, depending on each other. One solution
for breaking the circular dependency at playbook level:
- declare group A without dependencies
- declare group B depending on A
- declare group A depending on B
This patch breaks the dependency at module level. Whenever a depended-on
group is missing it's first created. This approach requires only two tasks:
- declare group A depending on B (group B will be auto created)
- declare group B depending on A
When creating a group EC2 requires you to pass the group description. In
order to fullfil this, rules now accept the `group_desc` param. Note
that group description can't be changed once the group is created so
it's nice to keep descriptions in sync.
Concrete example:
- ec2_group:
name: mysql-client
description: MySQL Client
rules_egress:
- proto: tcp
from_port: 3306
to_port: 3306
group_name: mysql-server
group_desc: MySQL Server
- ec2_group:
name: mysql-server
description: MySQL Server
rules:
- proto: tcp
from_port: 3306
to_port: 3306
group_name: mysql-client
* Added desired_capacity and vpc_zone_identifier to ec2_asg
* Use ec2_argument_spec() method and then remove unnecessary
declarations from argument_spec
* Remove AWS_REGIONS declaration
* Rename block_device_mappings to volumes to be consistent with ec2
* Remove all pep8 warnings except line length and continuation indent
* Use updated module_utils/ec2.py to add profile and security_token
support
* Remove mandatory arguments for delete to make launchconfig deletion
work
* Handle existing launch configurations better
* Improve output information
* Improve documentation