New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
jlopezalc opened this Issue Sep 7, 2016 · 16 comments

Comments

Projects
None yet
@jlopezalc
Copy link

jlopezalc commented Sep 7, 2016

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

This comment has been minimized.

Copy link

wraithm commented Sep 7, 2016

Same here

@wraithm

This comment has been minimized.

Copy link

wraithm commented Sep 7, 2016

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

@jlopezalc

This comment has been minimized.

Copy link

jlopezalc commented Sep 7, 2016

I'll try this @wraithm. Thanks!

@mitchellh mitchellh added bug core labels Sep 9, 2016

@ringods

This comment has been minimized.

Copy link
Contributor

ringods commented Dec 14, 2016

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

@jlopezalc

This comment has been minimized.

Copy link

jlopezalc commented Dec 14, 2016

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

@veqryn

This comment has been minimized.

Copy link

veqryn commented Feb 1, 2017

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

@jmickle

This comment has been minimized.

Copy link

jmickle commented Apr 4, 2017

Hitting this bug on 0.8.8

@jnevelson

This comment has been minimized.

Copy link

jnevelson commented Apr 5, 2017

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

@derFunk

This comment has been minimized.

Copy link

derFunk commented Apr 25, 2017

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

This comment has been minimized.

Copy link

oli-g commented Jun 15, 2017

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

Thank you!

@mattdodge

This comment has been minimized.

Copy link

mattdodge commented Jun 21, 2017

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

This comment has been minimized.

Copy link

wraithm commented Jun 21, 2017

@apparentlymart apparentlymart added cli and removed core labels Jun 21, 2017

@apparentlymart

This comment has been minimized.

Copy link
Contributor

apparentlymart commented Jun 21, 2017

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.

apparentlymart added a commit that referenced this issue Jun 22, 2017

command/format: minor adjustments to plan rendering
This change makes various minor adjustments to the rendering of plans
in the output of "terraform plan":

- Resources are identified using the standard resource address syntax,
  rather than exposing the legacy internal representation used in the
  module diff resource keys. This fixes #8713.

- Subjectively, having square brackets in the addresses made it look more
  visually "off" when the same name but with different indices were
  shown together with differing-length "symbols", so the symbols are now
  all padded and right-aligned to three characters for consistent layout
  across all operations.

- The -/+ action is now more visually distinct, using several different
  colors to help communicate what it will do and including a more obvious
  "(new resource required)" marker to help draw attention to this not
  being just an update diff. This fixes #15350.

- The resources are now sorted in a manner that sorts index [10] after
  index [9], rather than after index [1] as we did before. This makes it
  easier to scan the list and avoids the common confusion where it seems
  that there are only 10 items when in fact there are 11-20 items with
  all the tens hiding further up in the list.

apparentlymart added a commit that referenced this issue Jun 22, 2017

command/format: minor adjustments to plan rendering
This change makes various minor adjustments to the rendering of plans
in the output of "terraform plan":

- Resources are identified using the standard resource address syntax,
  rather than exposing the legacy internal representation used in the
  module diff resource keys. This fixes #8713.

- Subjectively, having square brackets in the addresses made it look more
  visually "off" when the same name but with different indices were
  shown together with differing-length "symbols", so the symbols are now
  all padded and right-aligned to three characters for consistent layout
  across all operations.

- The -/+ action is now more visually distinct, using several different
  colors to help communicate what it will do and including a more obvious
  "(new resource required)" marker to help draw attention to this not
  being just an update diff. This fixes #15350.

- The resources are now sorted in a manner that sorts index [10] after
  index [9], rather than after index [1] as we did before. This makes it
  easier to scan the list and avoids the common confusion where it seems
  that there are only 10 items when in fact there are 11-20 items with
  all the tens hiding further up in the list.
@wraithm

This comment has been minimized.

Copy link

wraithm commented Jun 22, 2017

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

@apparentlymart

This comment has been minimized.

Copy link
Contributor

apparentlymart commented Jun 22, 2017

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

This comment has been minimized.

Copy link
Contributor

apparentlymart commented Jun 22, 2017

I opened #15368.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment