[MM-61113] Allow multiple customizable subnets

[fmartingr]

Summary

• deployer config changes:
  • ClusterSubnetID -> ClusterSubnetIDs
  • ElasticsearchSettings.VPCID removed in favor of ClusterVpcId
• All resources are now matched with the selected VPC, following this logic:
  • If ClusterVPCIDs is not set, we use the first ubnet filtered from the aws_subnet.selected resource.
  • If ClusterVPCIDs is set, we use aws_subne.manual and manually pick an index from the resulting list for each resource that require a subnet to try and balance things out. RDS databases are sent all subnets. Check out this
• Using aws_subnet.manual to get the subnet list to prevent terraform trying to destroy the subnets or (if used with random_shuffle) recreate all resources when there has been no changes.
• Fixed a bug where we wouldn't wait for terraform stdout resulting in incomplete output from commands. 61f26c2

Ticket Link

https://mattermost.atlassian.net/browse/MM-61113

[streamer45]

Cool! A couple of high-level comments.

• deployer config changes:
  • ClusterVpcId -> ClusterVPCIDs

I don't see this change in here. I guess you meant ClusterSubnetID to ClusterSubnetIDs.

Also, is the implicit indexing driven by certain constraints or just simpler/quicker to implement? I am wondering whether a more structured setting could be easier/digestible (and potentially less error-prone) on the user side.

[fmartingr]

Cool! A couple of high-level comments.

• deployer config changes:

  • ClusterVpcId -> ClusterVPCIDs

I don't see this change in here. I guess you meant ClusterSubnetID to ClusterSubnetIDs.

Yeah, sorry. Edited.

Also, is the implicit indexing driven by certain constraints or just simpler/quicker to implement? I am wondering whether a more structured setting could be easier/digestible (and potentially less error-prone) on the user side.

What do you mean by this?

[streamer45]

Also, is the implicit indexing driven by certain constraints or just simpler/quicker to implement? I am wondering whether a more structured setting could be easier/digestible (and potentially less error-prone) on the user side.

What do you mean by this?

Having the specific index of ClusterSubnetIDs refer to a resource type feels perhaps a bit overengineered. Why not define an object with N named fields (one per resource type)?