terraform import command fails when there are several nested levels on the resource address

[jlopezalc]

Description

The terraform import command fails with an error message when you try to import a resource the was created from a module that has several nested levels.

Terraform Version

Terraform v0.7.3

Affected Resource(s)

AWS. Any resource created from a module with several nested subdirectories.

Expected Behavior

The terraform import command works fine and finally import the resource no matters how many levels it has.

Actual Behavior

The terraform import command fails when the resource address has several nested levels.

Steps to Reproduce

1. terraform get
2. terraform plan
3. Here We get several resources that we has created previously trough amazon console and We want to add them to the tfstate.
4. terraform import module.network.vpc.aws_vpc.vpc vpc-vpcxxxxid
5. Terraform informs us that there's an "unexpected value for instance type field" due several nested levels on the resource address.
   

   Details

Our main project structure is like this:

/
  modules
    - network
        - network.tf
        - private_subnet
            public_subnet.tf
        - public_subnet
            public_subnet.tf
        - vpc
            vpc.tf
    - rds
    - redshift
    - ...
  dev
    network.tf

The call to the modules occurs in this order:

from dev/network.tf:

        module "network" {
          source          = "../modules/network"
          ...

from modules/network/network.tf

        module "vpc" {
          source   = "./vpc"
          ...

from modules/network/vpc/vpc.tf

        resource "aws_vpc" "vpc" {
          cidr_block           = "${var.vpc_cidr}"
          ...

If We are inside dev directory and We execute a terraform import command We get this error message:

hostname:dev julian$ terraform import module.network.vpc.aws_vpc.vpc vpc-vpcxxxxid
Error importing: failed to parse resource address 'module.network.vpc.aws_vpc.vpc': Unexpected value for InstanceType field: "vpc"
hostname:dev julian$

And the import fails.

Workaround

We import the resource address with this command:
terraform import module.network.aws_vpc.vpc vpc-xxxxid

After this the resource is imported and We manually change the resource in the tfstate editing the file. If We move the resource with the command "terraform state mv source.address destination.address" We get an error too.

[wraithm]

Same here

[wraithm]

Actually, I just found a workaround, try:
terraform import module.network.module.vpc.aws_vpc.vpc vpc-xxxxid

[jlopezalc]

I'll try this @WraithM. Thanks!

[ringods]

Adding an additional module word in the target address according to the module nesting also seems to work for terraform state mv commands.

[jlopezalc]

Thanks @ringods! The workaround suggested by @WraithM works!

[veqryn]

@WraithM you just saved me a ton of time: i was stuck with the same bug but for mv commands.

[jmickle]

Hitting this bug on 0.8.8

[jnevelson]

I hit this on 0.9.2 when moving state. The workaround works there too 👍

[derFunk]

The same is valid for renaming/moving states! I'm currently refactoring one component out into a module, which itself is using a module as well.

This didn't work:
terraform state mv module.postgres.aws_db_instance.db module.mymodule.postgres.aws_db_instance.db.
Error message here: Error moving state: Unexpected value for InstanceType field: "db".

This worked:
terraform state mv module.postgres.aws_db_instance.db module.mymodule.module.postgres.aws_db_instance.db.

(Terraform v0.9.2)

[oli-g]

@mitchellh Any news from this? Is the team going to work on this soon?

Thank you!

[mattdodge]

I would actually even be ok with this behavior (having to write module twice). I would only request that the output of terraform plan would behave the same way.

[wraithm]

Seriously, the inconsistency is really strange.

On Jun 20, 2017 20:00, "Matt Dodge" [e-mail] wrote:

I would actually even be ok with this behavior (having to write module
twice). I would only request that the output of terraform plan would
behave the same way.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/hashicorp/terraform/issues/8713#issuecomment-309932741,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABcV0W-VhEYfYaKACuIZt4w6Xz_RG5Qzks5sGGsogaJpZM4J27gL
.

[apparentlymart]

Repeating the module. specifier for each level is the intended approach, since this disambiguates what could otherwise be a child module _or_ a resource type.

The terraform plan output is indeed inconsistent, and is one of a few places where some legacy forms show through from before we'd standardized on the resource addressing syntax. This in similar vein as #15342, which is about another way in which the plan output differs from the resource addressing syntax.

[wraithm]

@apparentlymart There's also the same inconsistency in terraform show, I believe. Does that PR fix that?

[apparentlymart]

It doesn't, but an open-ended issue like "fix all the inconsistencies" tends to be hard to track, so I'll make a new issue specifically for that one.

[apparentlymart]

I opened #15368.

[hashibot[bot]]

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.