You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When I implemented the aws_vpc_peering_connection data source in #10913 I did not keep to the convention of peer_vpc_id and peer_owner_id being either the accepter's or receiver's IDs relative to the current provider (see #10635), but made them absolute (i.e. always accepter's ID).
To keep this consistent with the aws_vpc_peering_connection resource (and aws_vpc_peering_connection_accepter resource - see #11505), I'd like to correct this.
The text was updated successfully, but these errors were encountered:
Because these attribute are used as part of the filter to identify the VPC Peering Connection and we don't know which side of the connection we are on, the idea of a relative peer doesn't apply here.
I suggest renaming the attributes to requester_vpc_id and accepter_vpc_id etc.
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
ghost
locked and limited conversation to collaborators
Apr 16, 2020
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
When I implemented the
aws_vpc_peering_connection
data source in #10913 I did not keep to the convention ofpeer_vpc_id
andpeer_owner_id
being either the accepter's or receiver's IDs relative to the current provider (see #10635), but made them absolute (i.e. always accepter's ID).To keep this consistent with the
aws_vpc_peering_connection
resource (andaws_vpc_peering_connection_accepter
resource - see #11505), I'd like to correct this.The text was updated successfully, but these errors were encountered: