Unable to change Flow Log to use log_destination instead of log_group_name

[ghost]

This issue was originally opened by @AMMullan as hashicorp/terraform#24419. It was migrated here as a result of the provider split. The original body of the issue is below.

---

Terraform Version

0.11.7

Terraform Configuration Files

resource "aws_flow_log" "flow_log" {
  # log_group_name = "${var.vpc_env}_flow_log"
  log_destination = "arn:aws:logs:${var.aws_region}:${var.account_id}:log-group:${var.vpc_env}_flow_log"
  iam_role_arn = "arn:aws:iam::${var.account_id}:role/flow_log_role_${var.aws_region}"
  vpc_id = "${module.vpc.vpc_id}"
  traffic_type = "ALL"
}

Expected Behavior

Trying to convert from using log_group_name to using log_destination - have updated the config (above) and see a new resource to be created, so delete the flow log from state and import the existing one (as per the docs) and it should show no changes.

Actual Behavior

We get identical changes as prior to updating/deleting/importing:

-/+ aws_flow_log.flow_log (new resource required)
      id:                   "fl-cd67a3a4" => <computed> (forces new resource)
      iam_role_arn:         "arn:aws:iam::[account_redacted]:role/flow_log_role_us-east-1" => "arn:aws:iam::[account_redacted]:role/flow_log_role_us-east-1"
      log_destination:      "" => "arn:aws:logs:us-east-1:[account_redacted]:log-group:mig-prod1_flow_log" (forces new resource)
      log_destination_type: "cloud-watch-logs" => "cloud-watch-logs"
      log_format:           "${version} ${account-id} ${interface-id} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${protocol} ${packets} ${bytes} ${start} ${end} ${action} ${log-status}" => <computed>
      log_group_name:       "mig-prod1_flow_log" => <computed>
      traffic_type:         "ALL" => "ALL"
      vpc_id:               "vpc-aaccaed1" => "vpc-aaccaed1"

I've also updated the state file manually so that the log_destination is as per the output and the log_group_name is "" but this changes nothing, we get the exact same as above.

Steps to Reproduce

1. Update config (comment out log_role_name and uncomment log_destination)
2. Execute terraform delete
3. Execute terraform import (as per the Terraform docs)
4. Execute terraform plan

Additional Context

We have a wrapper script around our terraform but this is just to simplify the way we have our Terraform structure across many accounts. We need to clean up all our TF so we can start looking at migrating to 0.12

[frimik]

Seems the log_destination attribute doesn't get imported?

[AMMullan]

Just verified that this is still an issue with 0.12.26 - i'd agree with @frimik that this looks like it's just not pulling the log_destination value and so the import isn't seeing it.

[bflad]

Hi folks 👋 The aws_flow_log resource isn't doing anything special with respects to reading the log_destination attribute into the Terraform state -- if the EC2 API includes it in the DescribeFlowLogs response, then it should be made available:

https://github.com/terraform-providers/terraform-provider-aws/blob/c6b48838da829723ef72245f5fb7b343e73fbaae/aws/resource_aws_flow_log.go#L223-L225

It appears that the EC2 API response may only include LogDestination if the Flow Log was created using LogDestination (see the second item in the example). Typically we have seen other AWS services populate new data like this when a new configuration method is introduced, but it seems that may not be the case here.

We have a few options here:

• Remove the deprecation from the log_group_name argument and instead only recommend the usage of log_destination for future proofing in the documentation rather than a warning during configuration validation
• Ask the EC2 service team to populate LogDestination in the response even for those created using LogGroupName, then the resource will work as expected here

In the meantime for existing flow logs, using the deprecated argument is okay for now and we will certainly not remove it as part of our 3.0.0 breaking changes.

[github-actions]

Marking this issue as stale due to inactivity. This helps our maintainers find and focus on the active issues. If this issue receives no comments in the next 30 days it will automatically be closed. Maintainers can also remove the stale label.

If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thank you!

[github-actions]

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.