Enhancement: Provide a workspace parameter to the import block

[adhodgson1]

Terraform Version

1.5.0

Use Cases

Given a pipeline with multiple environments, I want the import command to be made idempotent across all environments, only operating in the target environment.

Attempted Solutions

Our workaround currently is to target specific releases to the environments which we want to import, and then make sure the import commands are removed before pushing a new release through the entire environment lifecycle.

Proposal

It would be good to have an option of specifying the workspace where the import should take place. For example:

import {
  to = azurerm_network_security_group.nsg
  id = "/subscriptions/sub1/resourceGroups/rg1/providers/Microsoft.Network/networkSecurityGroups/nsg1"
  workspace = staging
}

import {
  to = azurerm_network_security_group.nsg
  id = "/subscriptions/sub2/resourceGroups/rg1/providers/Microsoft.Network/networkSecurityGroups/nsg1"
  workspace = production
}

References

No response

[crw]

Thanks for this feature request! If you are viewing this issue and would like to indicate your interest, please use the 👍 reaction on the issue description to upvote this issue. We also welcome additional use case descriptions. Thanks again!

Please see also, adjacent issue: https://github.com/hashicorp/terraform/issues/33228

[rohan472000]

Correct me if I'm wrong, but can we use the -state flag with the terraform import command. The -state flag can be used to specify the path to the state file for the target workspace. Look below for example:

                terraform import -state=path/to/stagging.tfstate azurerm_network_security_group.nsg 
                   /subscriptions/sub1/resourceGroups/rg1/providers/Microsoft.Network/networkSecurityGroups/nsg1

[adhodgson1]

@rohan472000 This issue isn't regarding the import command but the new import block that works with a standard Terraform plan or apply run.

[rohan472000]

For making import block idempotent across multiple environments, can we create a reusable Terraform module like idempotent_module or give any name. This module will accept variables for workspace and import_idempotent_details, inside the module, a conditional statement will be used to determine if the current environment matches the target workspace, ensuring import commands are executed only in the intended environment.

The module will have a block with a local-exec provisioner, enabling the execution of import commands using the provided import_idempotent_details. In the main Terraform configuration, the idempotent_module will be instantiated for each environment, with the appropriate workspace and import_idempotent_details specified.

Not sure that above will work or not, but tell me your thought on it.....

[adhodgson1]

Before going any further I wanted to just confirm you are talking about the same import blocks as detailed here: https://developer.hashicorp.com/terraform/language/import

[reed-hanger]

This would be great. Since the id strings must be literal, there's not a lot of wiggle room to use the same import block for multiple workspaces (assuming the underlying resource is different in each workspace). We're contemplating generating a unique .tf per workspace in our CI/CD process that contains the import block it uses, but it's an awkward workaround and, honestly, a lot of work when don't use imports that often.

[joewragg]

+1

[Exagone313]

This could be an alternative to the suggestion made in #33633

In the case where each environment is a different workspace, it could be used to put each id to import in a versioned tf file. Existing and specified workspaces will import the resource (with the given id), but new workspaces will be able to create a new resource without being affected by a bogus import block.