AWS security groups are unique by name only by VPC (Restated, the VPC
and group name form a unique key).
When attaching security groups to an ELB, the ec2_elb_lb module would
erroneously find security groups of the same name in other VPCs thus
causing an error stating as such.
To eliminate the error, we check that we are attaching subnets (implying
that we are in a VPC), grab the vpc_id of the 0th subnet, and filtering
the list of security groups on this VPC. In other cases, no such filter
is applied (filters=None).
EC2 Security Group names are unique given a VPC. When a group_name
value is specified in a rule, if the group_name does not exist in the
provided vpc_id it should create the group as per the documentation.
The groups dictionary uses group_names as keys, so it is possible to
find a group in another VPC with the name that is desired. This causes
an error as the security group being acted on, and the security group
referenced in the rule are in two different VPCs.
To prevent this issue, we check to see if vpc_id is defined and if so
check that VPCs match, else we treat the group as new.
While from the documentation[1] one would assume that replacing
CAPABILITY_IAM with CAPABILITY_NAMED_IAM; this as empirically been shown
to not be the case.
1: "If you have IAM resources, you can specify either capability. If you
have IAM resources with custom names, you must specify
CAPABILITY_NAMED_IAM."
http://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_CreateStack.html
Previously, when the attributes of a GCE firewall change, they were ignored. This PR changes that behavior and now updates them.
Note that the "update" also removes attributes that are not specified.
An overview of the firewall rule behavior is as follows:
1. firewall name in GCP, state=absent in PLAYBOOK: Delete from GCP
2. firewall name in PLAYBOOK, not in GCP: Add to GCP.
3. firewall name in GCP, name not in PLAYBOOK: No change.
4. firewall names exist in both GCP and PLAYBOOK, attributes differ: Update GCP to match attributes from PLAYBOOK.
Current module fails when tries to assign floating-ips to server that
already have them and either fails or reports "changed=True" when no
ip was added
Removing floating-ip doesn't require address
Server name/id is enough to remove a floating ip.
This parameter was actually added in 2.0. It's just that the
documentation in previous versions of the module were wrong (it said the
name was "network" rather than "name.) I've renamed the parameter in
the documentation of prior versions so ansible-module-validate should no
longer think that this is a new parameter.
The shade update_router() call will return None if the router is
not actually updated. This will cause the module to fail if we
do not protect against that.
The os_server module could automatically generate a floating IP for
the user with auto_ip=true, but we didn't allow for this FIP to be
automatically deleted when deleting the instance, which is a bug.
Add a new option called delete_fip that enables this.
Without this, ansible 2.1 will convert some arguments that are
meant to be dict or list type to their str representation.
Signed-off-by: Patrick Uiterwijk <puiterwijk@redhat.com>
The `source_dest_check` and `termination_protection` variables are being
assigned twice in ec2.py, likely due to an incorrect merge somewhere
along the line.
The IAM group modules were not receiving the `module` object, but they
use `module.fail_json()` in their exception handlers. This patch passes
through the module object so the real errors from boto are exposed,
rather than errors about "NoneType has no method `fail_json`".
* Change documented options for os_networks_facts
os_network_facts currently lists 'network' as an available option, taking the Name or ID. In Ansible 2.0.2 to 2.2.0, this is not valid. Options 'name' and 'id' should be used instead.
* Update os_networks_facts.py
* Update os_networks_facts.py
Set version_added to the only accepted value
* Update os_networks_facts.py
Removed inappropriate 'ID' parameter
