resource/aws_route: Support changing network_interface_id #2353
Conversation
The fix in hashicorp/terraform#7686 causes the exact same bug in reverse (if you specify network_interface_id in config, apply, and then change the network_interface_id, it will apply the old instance_id, which is a no-op). This checks which has changed from the instance state, allowing us to change either network_interface_id or instance_id correctly.
radeksimko
changed the title
|
looks like we have a check failing. Has anyone had time to assess or review criticality of the failure? |
|
Hi folks 👋 It looks like this old PR has merge conflicts, fails TravisCI testing, and hasn't seen an update in a long time since last asked so I'm going to close it. If there is interest in this still, please feel free to create a new PR and we'll review it. 👍 |
|
sorry for missing bcornils' message from june. as mentioned in the description, this PR depends on hashicorp/terraform#16693 (which introduces |
|
@bflad / @bcornils could I get this re-opened? alternatively, could I get eyes on hashicorp/terraform#16693 ? |
|
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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks! |
ghost
locked and limited conversation to collaborators
network_interface_idandinstance_idare both optional and computed. If you specify one, the other is computed byresourceAwsRouteSetResourceData.hashicorp/terraform#7686 made it so that if you specified
instance_id, applied, changed theinstance_id, and applied again, we would ignore the computednetwork_interface_id(an ENI on the old instance) and update theinstance_idcorrectly. This broke the opposite case (specifynetwork_interface_id, apply, change, apply again).This PR checks which has changed instead of preferring one over the other, fixing #2270. It depends on hashicorp/terraform#16693.