Open ophintor opened 4 years ago
I'm seeing this issue as well, where the false value is looking for a resource that I don't create when the variable is true. Thanks for opening this with great detail!
I've just hit this problem too, while trying to import a resource into state in a completely different part of the state hierarchy to a location which has an optional module (implemented with count
equal to 0
or 1
in a ternary depending on the value of some variable). The existence of the optional module could not be determined, which caused the import operation to fail.
What's more, the import operation at a CLI can look like it has succeeded – I get a line printed in green to imply it is successful, followed by a few deprecation warnings for code we haven't yet migrated, and this error is non-obvious at the end of some quite verbose Terraform output.
I don't really understand why the entire state tree needs to be exercised to import a single resource to another location in the state, where there are no dependencies between the branch of the tree to which I am importing and the branch where the optional resource resides. The optional resource was even toggled on in the workspace I was using – so the state even knew about the resource!
In the end, I worked around it by manually patching the HCL locally to bind the relevant interpolations statically, ran the import and then reverted the change. However, this behaviour is non-obvious/is not ergonomic and requires a moderate level of understanding of Terraform to debug.
In some cases, we absolutely depend on import
workflows – in this case, we had a cloud-based singleton resource which had to be side-loaded by hand due to side-effects of creating it through TF, so side-loading and import
was the only option. I'm trying to motivate other engineers to self-serve their own Terraform, but in busy environments, projects like this are going to preclude such ambitions from succeeding!
I had the same problem. :(
error message
Error: Configuration for import target does not exist
The configuration for the given import azurerm_application_insights_standard_web_test.my_resource does not exist. All target instances must have an associated configuration to be imported.
The problem was in import block.
FIX:
add [0] to the end of resource in import block
e.g. to = azurerm_application_insights_standard_web_test.my_resource[0]
Terraform Version
Terraform Configuration Files
Main file
Module main file
Actual Behavior
So this first step is probably expected behaviour. I will refer to the issue below, but this is still relevant.
When I run apply I get:
Which I suppose it makes sense.
So I do as suggested and run with target first:
So sg1 gets created.
Then I run terraform apply without a target. This time it works fine and creates the rest:
So far so good. Note that sg2 does not get created due to the condition.
But then let's say I remove the sg3 sec group from the state file:
And try to re-import it:
Why is this happening? Why are we looking at the locals and can't we avoid this issue?
Now, imagine in my main one I comment out the sg line so we create sg2:
I delete the sg3 manually from AWS (since it's not in the state any more) and run apply:
Removing and importing sg3 now works.
Why is this dependent on whether sg2 exists or not? Should not terraform be able to import it regardless?
Steps to Reproduce
As above.
Additional Context
This is a simple example that reflects an issue that we've experienced in a much more complex environment, but the outcome is the same. The resource that gets passed onto the module and that determines whether another resource is created or not, in our case is not declared at the root but is retrieved from a separate state file from a different set of configuration files as a data resource. I've made it this wat to simplify it but the outcome is the same.