Plannable Import: ID Interpolation

[bondsb]

Terraform Version

Terraform v1.5.0-beta1
on darwin_amd64

Use Cases

Interpolation of the import block id enables more complex import scenarios, allowing the user to specify identifiers through variables or other known values at plan time.

This feature enables easier import solutions for

• Pipelines
• Terraform Cloud
• Self-Service Solutions

It also provides a mechanism for automatic import, or "import-if-not-exists".

Attempted Solutions

The plannable import feature currently limits the value of the import block id to a constant string value. The following code snippet is not allowed:

resource "aws_instance" "web" {
    ...
}

import {
    to = aws_instance.web
    id = var.web_instance_id  # FAILS
}

Proposal

This proposal is an extension of the plannable import feature which is planned for inclusion in Terraform 1.5.

In this feature, the identifier may be specified by any interpolation that can be resolved at plan time. In this example (the same as the above example), we are now allowed to use a variable for an AWS instance ID:

resource "aws_instance" "web" {
    ...
}

import {
    to = aws_instance.web
    id = var.web_instance_id  # allowed now
}

The import block is ignored if id is null and a new resource will be created. Conditional import with variables makes it easier to import resources using pipelines or Terraform Cloud.

---

Automatic Import (import-if-not-exists)

For this scenario, we would like to import a web server if it exists or create a new one if it doesn't. The cloud provider creates a new ID every time we rebuild our infrastructure. But we know that the server will always be named "webserver1".

Let's use use a data source to check whether "webserver1" exists:

data "aws_instance" "existing_server" {
  filter {
    name   = "tag:Name"
    values = ["webserver1"]
  }
}

and import it only if it does:

resource "aws_instance" "web" {
    ...
}

import {
    to = aws_instance.web
    id = try(data.aws_instance.existing_server.id, null)  # if the server doesn't exist, create a new one
}

References

• Plannable import 3: Make import plannable #33085 (comment)
• Automatic Import Using Identifier Specification #27959
• Support import blocks in config #31910 (comment)
• Persistent state and automatic reimport for resources that aren't fully deleted on destroy #33216
• Import by declarative code over imperative command #26364

[crw]

Thanks for submitting this request!

[ilmax]

On top of what @bondsb suggested above, I would like to use import blocks NOT only in the root module.
When you have a complex infrastructure, it's a common practice to break it down in separate modules to make it more manageable.
In this scenario it would be preferred to be able to put the import blocks alongside the resource declarations, this will also allow/simplify using variables (or interpolation) in the import id that may not be available/in scope in the root module.

Is there a reason why import is only allowed on root modules or is it a just an initial limitation?

[omarismail]

Hey @ilmax, thanks for your input!

Is there a reason why import is only allowed on root modules or is it a just an initial limitation?

This is just the initial implementation. We do intend to expand import blocks within modules in future versions and are exploring a few ideas right now.

If you don't mind, it would be great hear more specific use cases and what you hope to achieve with having import{} within modules.

[ilmax]

If you don't mind, it would be great hear more specific use cases and what you hope to achieve with having import{} within modules.

Sure!

I'm going through a process of importing several thousands resources in terraform. I did half of the migration and I will have to do the other half soon.
So far I created some parametric script to import all the resources but it would have been nice to take advantage of the import block to simplify the process. I spent a quite some time writing those scripts and I ran into some issues like changing the terraform code and forgot to change the import script and so on.
On top of that the script was quite slow to execute because we don't have a bulk import, so every execution of the terraform import this that was refreshing all the datasources and that took A LOT of time.

What I would like to do is:

• Be able to put the import block close by to the resource it's importing
• Use variables and interpolations in the ID field (so I can use the same variables/interpolations used in the resource names where it makes sense)
• Be able to bulk import multiple resources at once without having to refresh each datasources for every import block (I'm expecting this to be already the case since import is executed during plan if I'm not mistaken)

This is my import wish list as of now :)

I'm really excited and looking forward to this feature because it seems to me that's a major improvement on the current state of the art regarding resource import

[omarismail]

@ilmax Thanks for providing this info! I'd love to spend time chatting. If you are open to it, please email me at oismail@hashicorp.com and we can schedule a time for a live chat to dig into this!

[ilmax]

Email sent!

[ncrothe]

Absolutely support the need for this. We're busy importing existing resources from multiple non-Terraform environments into corresponding Terraform states and need a way to say "If we're running this for environment X, please import using this ID".

[cmlccie]

This ☝️ would be helpful in modules to address singletons with IDs that follow known patterns. For example, consider AWS service-linked roles like the OpenSearch/ElasticSearch service-linked role, which will always have the same account-specific ID. If your module needs this this account-level singleton deployed, there is no good way to ensure the role is deployed and deployed only once.

With ID interpolation for import blocks, this could address singleton issues in modules where the IDs follow known patterns by allowing the module to import the existing resource (if present) and otherwise create the missing resource (if absent) - declaratively stating that the singleton resource must exist:

resource "aws_iam_service_linked_role" "elasticsearch" {
  aws_service_name = "es.amazonaws.com"
}

data "aws_caller_identity" "current" {}

import {
    to = aws_iam_service_linked_role.elasticsearch
    id = "arn:aws:iam::${data.aws_caller_identity.current.account_id}:role/aws-service-role/es.amazonaws.com/AWSServiceRoleForAmazonElasticsearchService"
}

[MoritzHorch]

For anyone who cant wait: We currently use a hacky workaround in our CI/CD to handle multiple environments / stages.

One could configure it like:

import {
  to = my_terraform_ressource.name
  id = "project/STAGE/the_ressource_id" # note the STAGE placeholder
}

And before running any terraform command in your pipeline one could use:

sed -i 's/STAGE'"$STAGE_VARIABLE"'/g' myfile.tf # replaces STAGE with the content of $STAGE_VARIABLE in myfile.tf

Works flawlessly right now.