Terraform v0.11.2
resource "azurerm_public_ip" "frontend" {
name = "frontend"
location = "${var.arm_location}"
resource_group_name = "${var.resource_group}"
public_ip_address_allocation = "static"
}
output "voyager.default_ingress.ip" {
value = "${azurerm_public_ip.frontend.ip_address}"
}
output.voyager.default_ingress.ip: Resource 'azurerm_public_ip.frontend' does not have attribute 'ip_address' for variable 'azurerm_public_ip.frontend.ip_address'
Output the ip_address
Cant find ip_address for that resource
It works on 1.0.1 azurerm provider, but dont on 1.1.0.
Same Terraform version
looks like terraform show for azurerm_public_ip includes everything but ip_address.
We are seeing the same issue.
This seems to be the change that might have broken the assignment for ip_address: https://github.com/terraform-providers/terraform-provider-azurerm/commit/b5c71c109d7ed3625f009a0928e40298e6fddd6b#r27187845
It is dependent on the props.DNSSettings instead of just on props.IPAddress.
๐ -- the data accessor workaround described here stopgaps this issue for me https://github.com/terraform-providers/terraform-provider-azurerm/issues/310
The data accessor works because that has not changed. It gets the ip from the iaas and can provide properties on it.
The resource for the public ip has changed and it does not set the property for the output to read from.
I also tested this. It broke all of our resources that reference the ip_address in order to create DNS entries and network security group rules in all of our existing configurations. I've locked the provider version to 1.0.1 until this is fixed.
Version 1.1.0 completely omits the ip_address in the state file, even after doing a refresh. Whoever is doing testing should add this to the regression testing for future versions of this resource.
๐ hey folks!
Firstly, sorry that this bug made it into this release (and for the delayed response here!)
@genevieve thanks for opening #772 with the fix for this issue, I've taken a look and it looks good to me (so I've merged it).
Whoever is doing testing should add this to the regression testing for future versions of this resource.
@TheLinuxNinja definitely - I've opened #789 which adds this acceptance test (I don't have permissions to push to @genevieve's fork - or I'd have added it to to #772 before merging).
Since #772 has been merged, we'll do a release early next week with this bug fix - for the moment it should be possible to workaround this by either using the Public IP Data Source or by pinning to the previous version of the AzureRM Provider via:
provider "azurerm" {
version = "1.0.1"
}
As #772 has been merged (and will be released early next week) and there's workarounds for this issue, I'm going to close this issue for the moment - but please feel free to reopen it. Apologies again that this bug slipped through - the acceptance tests added in #789 will ensure this doesn't happen again.
Thanks!
Thanks @tombuildsstuff!
Thanks @genevieve and @tombuildsstuff for this!
Been scratching my head a lot the last couple of days, so really nice we'll get a new release soon! :)
@KresoDenis @bwerthmann @genevieve @nik-shornikov @TheLinuxNinja just to let you know that the fix for this has been released in v1.1.1 :)
Yay, thank you.
Thanks. It was really nice to see this fixed so fast. It makes big difference to us.
We made fix on our side. But its always better to have it work on plugin side.
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. If you feel I made an error ๐ค ๐ , please reach out to my human friends ๐ [email protected]. Thanks!
Most helpful comment
@KresoDenis @bwerthmann @genevieve @nik-shornikov @TheLinuxNinja just to let you know that the fix for this has been released in v1.1.1 :)