Hello and thank you for this issue! The core team regularly reviews new issues and discusses them, but this can take a little time. Please bear with us while we get to your issue. If you're interested, the contribution guide has a section about the decision-making process.

Hi @rdash99 ,
Thanks for posting this.
Overall, it is a reasonable thing to support.
It can be a little tricky and will require an RFC to understand how we change the current implementation of the import block to support that.
I want to get more community input about that and hear about the different use cases by more people.

I feel like the use-case is under-specified.

It sounds like you're trying to create HCL that matches existing resources, then import the state for those existing resources. Yes?

And the issue is too many top-level files?

Hi, I can provide some background on our use case.

It sounds like you're trying to create HCL that matches existing resources, then import the state for those existing resources. Yes?

Yes, that is correct. In our case, we have a terraform module that encapsulates the creation of an AWS RDS instance together with other terraform resources. One of the options there is to export the logs to AWS Cloudwatch with this option. When used AWS creates a log group and send the logs there.
The log group creation is outside of terraform so we have no way of control over its parameters. Currently we use the hack below to "manage" the log groups.

The same situation happens when using AWS Lambda functions.

resource "terraform_data" "log_group_retention" {
  for_each = toset(data.aws_cloudwatch_log_groups.this.log_group_names)

  triggers_replace = [var.retention_in_days]
  provisioner "local-exec" {
    command = <<EOT
  aws logs put-retention-policy --log-group-name ${each.key} --retention-in-days ${var.retention_in_days}
  EOT
  }

  provisioner "local-exec" {
    when    = destroy
    command = "aws logs delete-log-group --log-group-name ${each.key}"
  }
}

resource "terraform_data" "log_group_tags" {
  for_each = toset(data.aws_cloudwatch_log_groups.this.arns)

  triggers_replace = [aws_db_instance.this.tags_all]
  provisioner "local-exec" {
    command = "aws logs tag-resource --resource-arn ${each.key} --tags '${local.cli_tag_string}'"
  }
}

And the issue is too many top-level files?

No, the issue is that the functionality is encapsulated in a module and OpenTofu doesn't allow importing inside a module only at the root level. We could ask everyone using our modules to "just import" the resources but that defeats the purpose of encapsulating the functionality inside a module.

Hope it helps :)

see same terraform issue and discussion: hashicorp/terraform#33474

Hi, I can add some extra context from my case too.

I'm using Gitops like repository, which calls local submodule (source = "./modules/xyz"), so it's all in one repo.
This submodule has some logic implemented, transforming inputs with a nested for loop into a local.xyz and use it to create resources with for_each.

But I also need to

import {
  for_each = local.xyz
  id = ...
  to = ...
}

Having to move the import statements to the root means all the associated logic has to be either moved to the root or duplicated for the time of resource imports.

Hey folks, I've moved this back to the queue for the core team to discuss.