Intermodule change should be avoided.

[fatz]

terraform-aws-vpc-peering/main.tf

Lines 108 to 128 in af2e48c

	resource "aws_security_group_rule" "this_sg" {
	provider = "aws.this"
	type = "ingress"
	from_port = 0
	to_port = 65535
	protocol = "all"
	cidr_blocks = ["${var.peer_cidr_block}"]
	security_group_id = "${var.this_security_group_id}"
	}
	resource "aws_security_group_rule" "peer_sg" {
	provider = "aws.peer"
	type = "ingress"
	from_port = 0
	to_port = 65535
	protocol = "all"
	cidr_blocks = ["${var.this_cidr_block}"]
	security_group_id = "${var.peer_security_group_id}"
	}

ok now I kinda understand the changes in security group module.

However I do not like the idea to make changes on resources another module is holding. As all local subnets and supernets are known before creation I'd rather suggest having each security group module doing this on their own and not here. Which means there is no need for introducing a breaking change to security groups

[bernadinm]

NACL was considered here but currently by default it allows all traffic already: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html#default-network-acl

This is the same for all security groups as well: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#DefaultSecurityGroup

Since this is the case that we're already configuring rules at the security group level, that would mean that if one terraform module wants to scale out, the other module would need to run to make sure that its rules are applied too for the hybrid cloud environment and this will cause problems with circular dependency for resources that potentially can come in and out of existence more often and the use of the data resource problem that was mentioned in hashicorp/terraform-provider-aws#7014

If we instead use a module where every module can look for i.e "internal" security group where any module can append or remove asynchronously without issue

[fatz]

lets have a chat about this in todays standup.

I still disagree in general. As the user has to decide on remote subnets anyways. We should not even try to have defaults for those subnets as it will lead to conflicts when users are not aware about this fact.

With that in mind there is already a static input about subnets on the top level module. which means we simply can have a variable containing all subnets. This list can be filtered and simply added by each module locally.