* Check mode fixes for ec2_vpc_net module
Returns VPC object information
Detects state change for VPC, DHCP options, and tags in check mode
* Early exit on VPC creation in check mode
The default VPC egress rules was being left in the egress rules for
purging in check mode. This ensures that the module returns the correct
change state during check mode.
By default, ssh-keygen will pick a suitable default for ssh keys
for all type of keys. By hardocing the number of bits to the
RSA default, we make life harder for people picking Elliptic
Curve keys, so this commit make ssh-keygen use its own default
unless specificed otherwise by the playbook
sysrc(8) does not exit with non-zero status when encountering a
permission error.
By using service(8) `service <name> enabled`, we now check the actual
semantics expressed through calling sysrc(8), i.e. we check if the
service enablement worked from the rc(8) system's perspective.
Note that in case service(8) detects the wrong value is still set,
we still output the sysrc(8) output in the fail_json() call:
the user can derive the exact reason of failure from sysrc(8) output.
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.
