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

dns_a_record_set resource fails when vcd_vapp resource explicitly set to use dhcp #1

Closed
hashibot opened this issue Jun 13, 2017 · 3 comments
Labels

Comments

@hashibot
Copy link

This issue was originally opened by @stubblyhead as hashicorp/terraform#13812. It was migrated here as part of the provider split. The original body of the issue is below.


Terraform Version

Terraform v0.9.3

Affected Resource(s)

  • vcd_vapp
  • dns_a_record_set
    (I'm not sure which of the two is at fault, possibly they are just not playing nice with each other)

Terraform Configuration Files

variable "name" {}
variable "user" {}
variable "password" {}

provider "vcd" {
  user = "${var.user}"
  password = "${var.password}"
  org = "myorg"
  url = "https://vcd/api"
  vdc = "mydatacenter"
  maxRetryTimeout = 180
}

resource "vcd_vapp" "susebox" {
  name = "${var.name}"
  catalog_name = "My Catalog"
  template_name = "opensuse13.2"
  network_name = "192.168.52.0/24"
  ip = "dhcp"
}

provider "dns" {
  update {
    server = "192.168.50.12"
  }
}

resource "dns_a_record_set" "suse" {
  zone = "myzone.lec."
  name = "${vcd_vapp.susebox.name}"
  addresses = [ "${vcd_vapp.susebox.ip}", ]
  ttl = 3600
}

Debug Output

  1. https://gist.github.com/stubblyhead/774633c1cd21050dc96cd0105d8b3126
  2. https://gist.github.com/stubblyhead/23878afa4ded3a876eaf906467b4a42d
    The first gist is a failed apply, and the second is a successful one. The only difference in configuration is explicitly using dhcp (gist 1) instead of implicitly using dhcp as the default behavior (gist 2).

Expected Behavior

What should have happened?
The configuration above should work as written. Commenting out line hashicorp/terraform#19 (ip = "dhcp") will result in a successful apply, but as dhcp is the default behavior it shouldn't matter if it's stated explicitly or not.

Actual Behavior

What actually happened?
The DNS entry does not get updated, and error text (see lines 633-654 in gist hashicorp/terraform#1 above) is output.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

  1. terraform apply
@hashibot hashibot added the bug label Jun 13, 2017
@bodgit
Copy link
Contributor

bodgit commented May 25, 2018

I don't think this is a bug in the DNS provider. You've set the ip attribute on the vcd_vapp.susebox resource to "dhcp" so the DNS provider is trying to literally use "dhcp" as the IP address and failing.

The vcd_vapp resource should probably handle this differently; as if you specify the ip attribute as "dhcp" then it gets replaced with whatever the actual IP address is, the next time you run a plan/apply, Terraform will surely want to set this back to "dhcp" again and cause a noisy diff.

@katbyte
Copy link
Contributor

katbyte commented Jun 5, 2018

Hi @stubblyhead,

I look a little deeper of a look and in addition to what @bodgit mentioned it appears this was a bug in the VCD provider that was fixed last summer after you opened this ticket and the provider should now correctly assign an ip to that property.

As such i am going to close this issue, however please don't hesitate to open another if this is still affecting you 🙂

@katbyte katbyte closed this as completed Jun 5, 2018
Copy link

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 23, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants