Provider configuration cannot depend on data sources during import

[jbardin]

As documented in Import: Provider Configuration, a provider used during import cannot depend on data sources for its configuration*.

As of v0.14, data sources can now be handled entirely during planning, which in principle works similarly to the import process. This means that it should be possible to expand and evaluate required data sources during import as well, as long as they themselves do not depend on any resource data which is not contained within the state.

---

*This shortcoming is no longer entirely true, a data source can be read from the existing state. The workaround for this case is to add the data source and refresh it immediately before running import. A state is required to refresh however, so if there has yet to be any created, applying a single null_resource will allow the refresh to complete, reading the data source into the state.

References:
This was mentioned in the comments of #13018, but the original cases presented there are no longer relevant in current releases.

[llamahunter]

These instructions are not exactly correct. Simply doing a targeted apply of a null_resource doesn't work. You have to do a targeted apply of the data sources that are needed to configure the provider. Only then will you be able to import state using those providers.

[jbardin]

Hi @llamahunter, the mention of the null resource is only to create a state if none exists at all, and targeting should not be required to read any data sources. If you however have managed resources which are required to do this, then those will need to be targeted separately for creation.

[llamahunter]

In this case, there was existing state. However, providers had been added to the top level, as they had been removed from modules. Needed to import some resources that changed names in the shuffle, but those resources depended on the new providers added at the top, which in turn depended on data sources also added to the top. Doing targeted applys of the data sources 'fixed' things so that the providers could be used during import.

[dkirrane]

What is the workaround? What does targeted applys of the data sources mean?
What is the workaround for Terraform Cloud?

terraform refresh

Error: error starting operation:

The "remote" backend does not support the "OperationTypeRefresh" operation.

terraform import azurerm_redis_cache.cache1 /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/group1/providers/Microsoft.Cache/Redis/cache1

Error: Invalid provider configuration

  on /mnt/c/dev/provider.tf line 26:
  26: provider "aiven" {

The configuration for provider["registry.terraform.io/aiven/aiven"] depends on
values that cannot be determined until apply.

Releasing state lock. This may take a few moments...

[mwarkentin]

I wonder if the refresh output should be updated?

❯ make refresh
Empty or non-existent state file.

Refresh will do nothing. Refresh does not error or return an erroneous
exit status because many automation scripts use refresh, plan, then apply
and may not have a state file yet for the first run.

data.aws_ssm_parameter.auth0_client_id: Refreshing state...
data.aws_ssm_parameter.auth0_client_secret: Refreshing state...

In this case refresh actually did do something, it allowed me to import my resources.. :)

[ecerulm]

If I'm not mistaken it's not just that a provider used during import cannot depend on data sources for its configuration". It's more that none of the provider configurations may depend on data sources if doing a terraform import.

So for example in my case I have 3 provider blocks:

• provider "aws"
• provider "kubernetes" (uses data)
• provider "helm" (uses data)

I'm trying to import a resource aws_iam_user (provider aws) so in principle it should not matter if the providers kubernetes or helm can be configured or not because for this particular import only the provider aws is used

terraform import 'module.airflow.module.airflow-logs_iam-user.aws_iam_user.this[0]' airflow-logs
terraform import
╷
│ Error: Invalid provider configuration
│ 
│   on xxxx/airflow/main.tf line 91:
│   91: provider "kubernetes" {
│ 
│ The configuration for provider["registry.terraform.io/hashicorp/kubernetes"] depends on values that
│ cannot be determined until apply.
╵

But as mentioned this can be workarounded by doing a targetted apply for the required data sources:

terraform apply -refresh-only -target data.aws_eks_cluster_auth.cluster  -target data.terraform_remote_state.eks
terraform import 'module.airflow.module.airflow-logs_iam-user.aws_iam_user.this[0]' airflow-logs
Import successful!

[gblues]

It might vary by backend, but with an s3 backend at least, I didn't need any resources to create the state. Simply doing a no-op apply of the provider + data was sufficient to allow me to import the resource.

[kriswuollett]

Would like to see a solution that supports an import during a cold start. I'm learning with terraform-provider-digitalocean's kubernetes example. Besides the base example itself, I'm adding a VPC to be referenced by the digitalocean_kubernetes_cluster. The VPC may already exist in DigitalOcean so I'd want to import it. But in the cold start case the cluster does not exist yet to refresh to dynamically configure the kubernetes and helm providers. Is my only choice to comment out the k8s module, import the VPC, apply, include the k8s module, and apply again?

[dkirrane]

In my case my provider depended on a api_token sensitive variable, set in the Terraform Cloud workspace.
Using export TF_VAR_api_token=foo before running import didn't work, possibly because I need to use jsondecode function on the variable

provider "aiven" {
  alias = "aiven"
  api_token = jsondecode(var.api_token)
}

Terraform import fails with

Error: Invalid provider configuration

  on /mnt/c/dev/provider.tf line 26:
  26: provider "aiven" {

The configuration for provider["registry.terraform.io/aiven/aiven"] depends on
values that cannot be determined until apply.

I had to do 2 ugly hacks to get import working.

1. Add an alias to the provider.
2. Manually add a string instead of a variable for the api_token. jsondecode function use in provider is an issue for import.
3. Run terraform import
4. Remove ugly hacks 1 & 2

provider "aiven" {
  alias = "aiven"
  api_token = "foo"
}

Then in modules using the provider I had to pass the aliased provider.

module "aiven" {
  source  = "app.terraform.io/XXX/aiven"
  version = "1.0.0"

  providers = {
    aiven   = aiven.aiven
  }

I'm using Terraform v0.14.9

[iosifnicolae2]

Does anyone has a workaround for this problem?

[kriswuollett]

@iosifnicolae2, I split my project into multiple states like infra (the IaaS) and services (Kubernetes). The infra project writes out files like a kubeconfig and SSL certificates to be consumed by the services project. See the Remote State documentation and the the related issue #2430.

[dvcrn]

My setup relied on remote variables that didn't work with this either. As a hacky workaround, I commented out all dynamic things (like vars/data) it complained about, then replaced the var.xxx variables with hardcoded values (passed vars or passed through env didn't work). Once it passed I switched everything back.

[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.