elbv2/listener,target_group: Fix import differences, zero-values for absent values #39413
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Community NoteVoting for Prioritization
For Submitters
|
github-actions
bot
added
tests
github-actions
bot
added
the
documentation
YakDriver
changed the title
jar-b
approved these changes
Sep 20, 2024
There was a problem hiding this comment.
LGTM 🎉
% make testacc PKG=elbv2 TESTS=TestAccELBV2Listener_forwardImport
make: Verifying source code with gofmt...
==> Checking that code complies with gofmt requirements...
TF_ACC=1 go1.22.7 test ./internal/service/elbv2/... -v -count 1 -parallel 20 -run='TestAccELBV2Listener_forwardImport' -timeout 360m
--- PASS: TestAccELBV2Listener_forwardImport (235.08s)
PASS
ok github.com/hashicorp/terraform-provider-aws/internal/service/elbv2 240.222s| @@ -12,6 +12,8 @@ Provides a Load Balancer Listener resource. | |||
|
|
|||
| ~> **Note:** `aws_alb_listener` is known as `aws_lb_listener`. The functionality is identical. | |||
|
|
|||
| ~> **Note:** When importing a listener with a forward-type default action, if the default action contains a top-level target group ARN or a forward action with a target group ARN, you may need to include both in the configuration to avoid import differences. | |||
There was a problem hiding this comment.
Would it make sense to move this under the Import heading?
github-actions
bot
removed
the
prioritized
|
This functionality has been released in v5.69.0 of the Terraform AWS Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you! |
|
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
TL;DR
Importing setting absent values
When importing, the issue of incorrectly setting Go zero-values for absent values should be fixed for
aws_lb_listener,aws_alb_listener,aws_lb_target_group, andaws_alb_target_group. It is difficult to test for all situations so please open a new issue if you find new problems.Importing listeners with forward type default actions
During import, it's impossible to determine from AWS's response, the config, the state, or the plan whether the target group ARN was defined at the top level or within a forward action target group. AWS returns ARNs in both the default action (top-level) and in at least one forward action target group, regardless of whether a forward action target group is actually defined.
As a result, there was no clean way to fix this issue. However, as a workaround, we have removed the limitation preventing providing both
default_action.0.target_group_arnanddefault_action.0.forward. The AWS API allows this, stating: "You can specify both a target group list and a top-level target group ARN only if the ARNs match." As a result, for default action configurations with one target group, you can avoid import differences by defining ARNs in both places.Additional
One of the challenges we’re facing here is that what we send to AWS doesn’t always match perfectly with what AWS sends back to us. Let’s take the example of a listener’s default action.
When we send a default action that only includes
orderandtype, AWS responds with additional information, like aforwardconfiguration. In most cases—during create, refresh, or update operations—we have access to the Terraform configuration and state, so we can work with this extra information and adjust things accordingly.However, during the import process, things are different. Since Terraform doesn’t have access to the configuration or state after an import (which we agree is not ideal and may be improved in future versions), it becomes difficult to handle this mismatch.
Here’s where the problem occurs: After an import, when we ask AWS for the listener’s default action, AWS sends back the
order,type,target_group_arn, and aforwardconfiguration that also includes atarget_group_arn. Without the original configuration or state, we’re left guessing what the config might have been so we can properly set up the state in Terraform.In most cases across the Terraform AWS provider, we can figure this out without any issues and everything matches up. But for listeners, we hit a scenario where it’s impossible to tell whether the Terraform configuration did or did not specify a
forward. As a result, both thedefault_action'starget_group_arnand theforward'starget_group_arnare set. This matches what the API does.Our meager fix to this is to, like the API, allow setting ARNs in both places, as long as they match. This should only be necessary for configurations where 1) importing is a priority, and 2) you must avoid import differences.
Relations
Closes #37211
Closes #38861
References
Output from Acceptance Testing