`import RESOURCE_TYPE` subcommands (=> easier coding & shell completion)

[Dominik-K]

A subcommand with the resource name for the import subcommand would be very helpful to start transforming to Terraform. As an example:

terraform import aws_route53_record TF_NAME  --name=dev.example.com --type=NS --zone_id=Z4KAPRWWNC7JR --set_identifier=dev

instead of

terraform import aws_route53_record.TF_NAME  Z4KAPRWWNC7JR_dev.example.com_NS_dev

• Importing would be easier as it's easier to create shell completions for it.
• With shell completion, there's no/less need consulting the documentation how to construct the ID for a specific resource.
• It's easier to understand just while reading an example with included values (just try to understand current import command above from itself).
• No strange bugs with underscores in parts of the ID. E.g. https://github.com/terraform-providers/terraform-provider-aws/issues/771 (that bug inspired this idea).
• Structuring objects in subcommands is a near-to standard at newer infrastructure CLI tools, e.g. Moby (former Docker), Kubernetes (both use Cobra CLI framework), AWS & GCloud.

[apparentlymart]

Hi @Dominik-K! Thanks for these ideas.

Looks like there's two different ideas packed in here:

• Use a separate arg for the resource type and the name, rather than using a resource address. This is a little tricky because the current form is more general than just types and names; you can, for example, import to aws_instance.server[1] to import into something that has count, or to module.foo.aws_instance.server to import into a child module. I definitely take the point on the ease of implementing autocomplete there, though; we've talked before about giving Terraform a built-in autocomplete driver that could then understand the various syntaxes, but that is indeed harder than just splitting these things up separately. Something we'll have to think about...
• Importing with multiple arguments rather than just a single id. This is something that's been discussed a bunch before, and agreed that it would be a big improvement. The initial pass of import was focused on things that have very obvious unique ids, like EC2 instances. It didn't scale very well to things that have composite or synthetic ids, like Route53 records. We plan to do another pass on import in future to address both this and also auto-generation of configuration for imported resources, but the details for that are not fully fleshed out yet and we likely need to do some other foundational work first.

Thanks for taking the time to write this up. All good feedback here, and we'll take it into consideration once we get into the more detailed planning for improvements to import.

[Dominik-K]

Thanks for your fast and detailled answer @apparentlymart.

I've just found a similar issue: it's more convenient to write

 terraform state mv aws_route53_record OLD_NAME NEW_NAME 

instead of

 terraform state mv aws_route53_record.OLD_NAME aws_route53_record.NEW_NAME

Maybe that's a good newcomer task, isn't it?

[apparentlymart]

That runs into some of the same concerns I mentioned above: the ability to move things is more general than just changing the name. Possibly we could have a shorthand that if the second argument contains no dots we automatically assume it's a new name for the first argument, leaving everything else unchanged:

terraform state mv aws_route_53_record.OLD_NAME NEW_NAME

...but I'm not sure if there would be unintended consequences for that. :confused:

I think the work here would be mainly in command/state_mv.go. If you'd be interested in building a prototype to help think through and test for any non-obvious problems then that'd be appreciated! But I just want to be explicit that there is a conflict here that these state commands can be potentially destructive so we have generally leaned towards being explicit, at the expense of being verbose, since that gives us better opportunity to validate the arguments and help avoid mistakes. We'd need to make sure that a change here doesn't impact our ability to do these checks.

[james-flynn-ie]

@apparentlymart, do we want to close this issue due to its age?