Sugestion: aws_route53_record allow_overwrite should have the default value to false

[marcosdiez]

Terraform Version

Terraform v0.11.5
+ provider.aws v1.11.0

Affected Resource(s)

• aws_route53_record

Terraform Configuration Files

provider "aws" {
  version = "1.11"
  region  = "us-east-1"
}

resource "aws_route53_record" "www_d2" {
  zone_id = "ZZZZZZZZZZZZZZ"
  name    = "marcos_test.AAAAAAAAA.com"
  type    = "A"
  ttl     = "300"

  #   allow_overwrite = "false"
  records = ["10.10.10.20"]
}

Sugestion

One of the nice things about terraform is that it only fiddles with resources it created (unless one explicitly uses terraform import)

That means one can be certain that he or she won't step on nobody else's toes while using terraform.

Weirdly, that does not happen with aws_route53_record.
It simply overwrites existing records as if they did not matter.
@Erouan50 was nice enough to create a parameter called allow_overwrite exactly to prevent that behavior.

Nevertheless the default value is true. I deeply believe it should be false. The former is counter intuitive and when one notices, it may be too late. Although this is a behavior change, it's the same as adding a sit belt to the existing process. More or less like terraform --apply is not automatic now.

Please consider changing the default value of allow_overwrite to false

References

Are there any other GitHub issues (open or closed) or Pull Requests that should be linked here? For example:

• Added option to avoid DNS record overwrite #2926

[bflad]

Hi @marcosdiez 👋 When the original resource was written (quite a long time ago), it was set to always use the UPSERT action on resource creation, as you said, contrary to how almost all Terraform resources since then operate on creation. In order to introduce non-breaking behavior to the existing resource, the allow_overwrite flag was introduced to allow you to opt into the CREATE action on resource creation so it properly errors. The allow_overwrite flag is a workaround and opportunity to allow the community to ensure their environments and configuration are ready for when the potentially breaking change occurs to flip the resource creation behavior. We do not intend to introduce breaking compatibility without a major version increase.

The eventual plan is to switch the behavior to always use the CREATE action on resource creation and potentially remove the allow_overwrite flag in the next major version (2.0.0) of the AWS provider. We do not have a specific release date for this yet.

[marcosdiez]

That's a very sane decision.
Congratulations for such a wise choice!

Marcos

[bflad]

The behavior of requiring imports for existing infrastructure is now the default in version 2.0.0, releasing later this week. The allow_overwrite option will still be available as a deprecated flag to allow operators time to fix their workflows before another future major release which removes the flag.

[ghost]

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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!