aws_route53_zone imports with a trailing dot

[TaiSHiNet]

Hi,

I'm on version 0.7.1 and when running an aws_route_53 import it'll end up in the state file with a trailing dot (as in bind, and as shown in the console).
This causes the resource to try and be recreated due to a mismatch with the terraform file.
How to reproduce:

Create a Route53 zone manually
Create the TF resource in a file
Import Route53 zone into your state
Run terraform plan

I could have just bypassed this by by adding a trailing dot to the resource, but documentation shows an example without it and it might be misleading to have both ways.

Bests

[kwilczynski]

We can just strip the trailing-dot, as per the documentation:

The name of the domain. This must be a fully-specified domain, for example, www.example.com. The trailing dot is optional; Amazon Route 53 assumes that the domain name is fully qualified This means that Amazon Route 53 treats www.example.com (without a trailing dot) and www.example.com. (with a trailing dot) as identical.

[kwilczynski]

Actually, after thinking about this. Perhaps it is better to update the documentation.

Fixing this would affect many people and would require a migration, quite possibly.

Thus it might not be worth it. What do you think @stack72 ?

[apparentlymart]

If Route53 considers the two to be equivalent, we could add a StateFunc to the attribute that normalizes the value by stripping it off... this would prevent Terraform from creating a diff related to trailing dots.

[kwilczynski]

@apparentlymart oh yes! Thank you for that.

[kwilczynski]

@apparentlymart I had to exclude name from import test, otherwise it would complain about the difference. Any idea how to solve this differently? I feel so-so about this.

[apparentlymart]

@kwilczynski I'm not too familiar with the import system, so I'm not sure what the requirements are there. Hopefully there's a similar sort of normalization mechanism in that layer, but I'll have to defer to @mitchellh on this one.

[stack72]

@kwilczynski we may need a custom migration for this rather than just using the Passthrough - look at how security_group_rule imports work

[kwilczynski]

@apparentlymart @stack72 @mitchellh this change works for normal operation but not for the imports, as per:

resource "aws_route53_zone" "test" {
  name = "terrraform.test"
}

$ ./terraform import aws_route53_zone.test Z3SOE6CTJLP957
provider.aws.region
  The region where AWS operations will take place. Examples
  are us-east-1, us-west-2, etc.

  Default: us-east-1
  Enter a value:

aws_route53_zone.test: Importing from ID "Z3SOE6CTJLP957"...
aws_route53_zone.test: Import complete!
  Imported aws_route53_zone (ID: Z3SOE6CTJLP957)
aws_route53_zone.test: Refreshing state... (ID: Z3SOE6CTJLP957)

Import success! The resources imported are shown above. These are
now in your Terraform state. Import does not currently generate
configuration, so you must do this next. If you do not create configuration
for the above resources, then the next `terraform plan` will mark
them for destruction.

$ ./terraform plan
provider.aws.region
  The region where AWS operations will take place. Examples
  are us-east-1, us-west-2, etc.

  Default: us-east-1
  Enter a value:

Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but
will not be persisted to local or remote state storage.

aws_route53_zone.test: Refreshing state... (ID: Z3SOE6CTJLP957)

The Terraform execution plan has been generated and is shown below.
Resources are shown in alphabetical order for quick scanning. Green resources
will be created (or destroyed and then created if an existing resource
exists), yellow resources are being changed in-place, and red resources
will be destroyed. Cyan entries are data sources to be read.

Note: You didn't specify an "-out" parameter to save this plan, so when
"apply" is called, Terraform can't guarantee this is what will execute.

-/+ aws_route53_zone.test
    comment:        "This is a test" => "Managed by Terraform"
    force_destroy:  "" => "false"
    name:           "terrraform.test." => "terrraform.test" (forces new resource)
    name_servers.#: "4" => "<computed>"
    vpc_region:     "" => "<computed>"
    zone_id:        "Z3SOE6CTJLP957" => "<computed>"


Plan: 1 to add, 0 to change, 1 to destroy.

It seems that the import mechanism is not respecting the StateFunc which might be by design, or not. I am not sure yet.

[kwilczynski]

As per @stack72 (via Slack) we need a custom import to solve this.

[kwilczynski]

So, the custom import will require a lot of duplication from the ReadFunc, thus a re-factor is in order.

[martijnvermaat]

What would be the workaround in the meantime?

[kwilczynski]

@martijnvermaat hi there! I am sorry that you are having the same problem! And my sincere apologies for the delay. I've been busy with my day work having less time as of late to work on this, I am very sorry!

[martijnvermaat]

That's allright @kwilczynski . I tested a workaround by manually removing the trailing dot from the state file. I think that's basically what your PR would do.

[kwilczynski]

@martijnvermaat hi! That is what the initial Pull Request did, very true. But then I realised that it would not work for importing. To make it work for both import and normal operations e.g. plan, refresh, apply, etc., one needs to provide bespoke import routine, rather than rely on simple passthrough. Which is more time consuming to do.

Your work around seem sensible.

Again, apologise.

[jflammia]

Just wondering if there is any update on this issue. I hit it all the time. More of an annoyance at this point but it would be nice if it were resolved 👍

[thalesac]

Useful example if you're retrieving the domain using data and would like to remove the trailing dot: ${replace(data.aws_route53_zone.selected.name, "/[.]$/", "")

[leventyalcin]

This is still exist

-/+ module.route53_setup.aws_route53_zone.private (new resource required)
      id:                 "XXXXXXXXXXXXXX" => <computed> (forces new resource)
      comment:            "Apex domain" => " Apex domain"
      force_destroy:      "" => "false"
      name:               "th.com." => "th.com" (forces new resource)
      name_servers.#:     "4" => <computed>
      vpc_region:         "" => <computed>
      zone_id:            "XXXXXXXXXXXXXX" => <computed>

Terraform v0.11.1
+ provider.archive v0.1.0
+ provider.aws v1.6.0
+ provider.template v0.1.1

I needed to pull/edit/push the remote state file after the import.

[bflad]

Hi, @leventyalcin. 👋 Sorry you ran into trouble during your aws_route53_record import. The trailing dot import issue you mention should be resolved as of v1.10.0 of the AWS provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

[developerinlondon]

@bflad this still exists on provider.aws v1.11.0:

-/+ module.route53_setup.aws_route53_zone.public (new resource required)
      id:                 "XXXXXXXXXXXXXX" => <computed> (forces new resource)
      comment:            "domain" => "domain"
      force_destroy:      "" => "false"
      name:               "th.com." => "th.com" (forces new resource)
      name_servers.#:     "4" => <computed>
      zone_id:            "XXXXXXXXXXXXXX" => <computed>

$ terraform --version
Terraform v0.11.1
+ provider.archive v0.1.0
+ provider.aws v1.11.0
+ provider.template v0.1.1

[developerinlondon]

A simple workaround is to pull in the remote state, edit it and then push it back up. Eg:

 terraform state pull >./current.tfstate
 terraform state push ./current.tfstate

[mbainter]

I ran into this problem this past week with:

Terraform v0.11.7
+ provider.aws v1.21.0

@developerinlondon's workaround worked for me.

[e1senh0rn]

Just ran into this issue.

Terraform v0.11.8
+ provider.aws v1.33.0

@bflad, it seems it was fixed for record, but not for zone.

[bflad]

Oops thanks for the heads up and sorry for jumping to the wrong conclusion there regarding aws_route53_zone vs aws_route53_record since the fix was only for the latter. I'll reopen the downstream AWS provider issue for aws_route53_zone that was created from this one: hashicorp/terraform-provider-aws#241

Since this issue is generating notifications in the wrong place now (providers were split from Terraform core back in Terraform 0.10), I am going to lock this issue to encourage 👍 reactions and comments on: hashicorp/terraform-provider-aws#241