Skip to content
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

provider/aws: route53_record - "fqdn" is missing during first apply #2233

Closed
jamestoyer opened this issue Jun 4, 2015 · 6 comments · Fixed by #2528
Closed

provider/aws: route53_record - "fqdn" is missing during first apply #2233

jamestoyer opened this issue Jun 4, 2015 · 6 comments · Fixed by #2528

Comments

@jamestoyer
Copy link

I seem to be having a problem displaying the fqdn property on a Route 53 record when using it with an output. The output variable does not appear at the end of the apply stage with all my other outputs.

I have the output set up as

output "web_fqdn" {
  value = "${aws_route53_record.web.fqdn}"
}

And I have the following Route 53 record set up as

resource "aws_route53_record" "web" {
   zone_id = "${var.dns_domain_zone_id}"
   name = "web.${var.dns_domain}"
   type = "CNAME"
   ttl = "300"
   records = ["${aws_elb.web.dns_name}"]
}

The apply stage was run using Atlas (and the rather awesome GitHub integration), so it's version 0.5.3, as far as I can see.

The actual record was created correctly, and I've verified it exists. So far I've only tested this on the creation of a record, and not subsequent applies, i.e. when the record already exists and it's not been updated.

@jamestoyer
Copy link
Author

Just to post an update.

I've just done an apply on Atlas, which used v0.6.0-dev. This time I was not updating the Route 53 records (there were other changes to an ELB), and the output appeared as expected.

@radeksimko
Copy link
Member

@jamestoyer Thanks for reporting this.

I can confirm that fqdn is missing in the output in the first apply run.
Here's a snippet of code I was testing:

variable "dns_domain" {
  default = "notexample.com"
}

resource "aws_route53_zone" "primary" {
  name = "${var.dns_domain}"
}

resource "aws_route53_record" "web" {
  zone_id = "${aws_route53_zone.primary.id}"
  name = "web.${var.dns_domain}"
  type = "CNAME"
  ttl = "300"
  records = ["${aws_elb.web.dns_name}"]
}

resource "aws_elb" "web" {
  name = "foobar-terraform-elb"
  availability_zones = ["us-west-2b", "us-west-2c"]

  listener {
    instance_port = 80
    instance_protocol = "http"
    lb_port = 80
    lb_protocol = "http"
  }
}

output "web_fqdn" {
  value = "${aws_route53_record.web.fqdn}"
}

output "web_name" {
  value = "${aws_route53_record.web.name}"
}

after 1st terraform apply:

Apply complete! Resources: 3 added, 0 changed, 0 destroyed.

...

Outputs:

  web_name = web.notexample.com

2nd terraform apply:

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

Outputs:

  web_fqdn = web.notexample.com
  web_name = web.notexample.com

@radeksimko radeksimko changed the title Route 53 fqdn not working with outputs provider/aws: route53_record - "fqdn" is missing during first apply Jun 13, 2015
@sheldonh
Copy link

Is this about aws_route53_record not waiting long enough to confirm that the resource has been created? This is in my way, and I'm keen to take a poke at it.

@catsby
Copy link
Contributor

catsby commented Jun 26, 2015

I opened #2528 to patch this; TL;DR we typically call update after create, and update typically calls read.

Here we just quit after create, so calling read at the end populates the fqdn attribute

@catsby
Copy link
Contributor

catsby commented Jun 26, 2015

#2528 was merged, thanks for reporting this issue!

@ghost
Copy link

ghost commented May 1, 2020

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.

@ghost ghost locked and limited conversation to collaborators May 1, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants