(Datasource) NSX-T Edge gateway Plugin chrashes when reading Egde gateway with allocated IPv6 addresses.

[Nagte502]

Description

Hi! We are experiencing an issue with the datasource 'vcd_edgegateway' when the edge has IPv6 addresses allocated.
When using this datasource on an edge gateway that has ipv6 IP allocations, we get the following error:

When removing the IPv6 allocation from the edge, the plugin works fine. Does the plugin not support IPv6 yet? Can this be fixed.

If you need any more information, please let me know. Would love to see this fixed as soon as possible :)

Terraform vcd provider version v3.11.0

---

Error as text for copying purpoises:

│ Error: Plugin did not respond
│
│ with module.kpn-vcd-framework-module.module.vcd_nsxt_edgegateways[0].data.vcd_nsxt_edgegateway.nsxt-edge,
│ on .terraform/modules/kpn-vcd-framework-module/modules/networking/vcd_nsxt_edgegateway/main.tf line 1, in data "vcd_nsxt_edgegateway" "nsxt-edge":
│ 1: data "vcd_nsxt_edgegateway" "nsxt-edge" {
│
│ The plugin encountered an error, and failed to respond to the
│ plugin.(*GRPCProvider).ReadDataSource call. The plugin logs may contain
│ more details.
╵

Stack trace from the terraform-provider-vcd_v3.11.0 plugin:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0xd2aa54]

goroutine 86 [running]:
github.com/vmware/terraform-provider-vcd/v3/vcd.setNsxtEdgeGatewayUplinkData(0xc0001d6840?, 0xc0006cf300, 0xd?)
github.com/vmware/terraform-provider-vcd/v3/vcd/resource_vcd_nsxt_edgegateway.go:1059 +0xcf4
github.com/vmware/terraform-provider-vcd/v3/vcd.setNsxtEdgeGatewayData(0xc00061cf50, 0xc000448910, 0xf?)
github.com/vmware/terraform-provider-vcd/v3/vcd/resource_vcd_nsxt_edgegateway.go:938 +0x250
github.com/vmware/terraform-provider-vcd/v3/vcd.datasourceVcdNsxtEdgeGatewayRead({0x12256b8?, 0xc0000bbd40?}, 0x0?, {0x105c900?, 0xc00061cf50})
github.com/vmware/terraform-provider-vcd/v3/vcd/datasource_vcd_nsxt_edgegateway.go:270 +0x577
github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*Resource).read(0xc0003a3880, {0x12256b8, 0xc0000bbd40}, 0xd?, {0x105c900, 0xc00061cf50})
github.com/hashicorp/terraform-plugin-sdk/[email protected]/helper/schema/resource.go:795 +0x11b
github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*Resource).ReadDataApply(0xc0003a3880, {0x12256b8, 0xc0000bbd40}, 0xc000561600, {0x105c900, 0xc00061cf50})
github.com/hashicorp/terraform-plugin-sdk/[email protected]/helper/schema/resource.go:1015 +0x149
github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*GRPCProviderServer).ReadDataSource(0xc000137920, {0x12256b8?, 0xc0000bad50?}, 0xc00009c1e0)
github.com/hashicorp/terraform-plugin-sdk/[email protected]/helper/schema/grpc_provider.go:1237 +0x366
github.com/hashicorp/terraform-plugin-go/tfprotov5/tf5server.(*server).ReadDataSource(0xc000242460, {0x12256b8?, 0xc00051f020?}, 0xc000236af0)
github.com/hashicorp/[email protected]/tfprotov5/tf5server/server.go:699 +0x3df
github.com/hashicorp/terraform-plugin-go/tfprotov5/internal/tfplugin5._Provider_ReadDataSource_Handler({0x101dec0?, 0xc000242460}, {0x12256b8, 0xc00051f020}, 0xc0006f76c0, 0x0)
github.com/hashicorp/[email protected]/tfprotov5/internal/tfplugin5/tfplugin5_grpc.pb.go:503 +0x169
google.golang.org/grpc.(*Server).processUnaryRPC(0xc00027e000, {0x122a818, 0xc000583860}, 0xc000528b40, 0xc0004268a0, 0x18cb9c8, 0x0)
google.golang.org/[email protected]/server.go:1358 +0xe15
google.golang.org/grpc.(*Server).handleStream(0xc00027e000, {0x122a818, 0xc000583860}, 0xc000528b40, 0x0)
google.golang.org/[email protected]/server.go:1735 +0x9e7
google.golang.org/grpc.(*Server).serveStreams.func1.1()
google.golang.org/[email protected]/server.go:970 +0xbb
created by google.golang.org/grpc.(*Server).serveStreams.func1 in goroutine 40
google.golang.org/[email protected]/server.go:981 +0x145

Error: The terraform-provider-vcd_v3.11.0 plugin crashed!

This is always indicative of a bug within the plugin. It would be immensely
helpful if you could report the crash with the plugin's maintainers so that it
can be fixed. The output above should help diagnose the issue.

[dataclouder]

Hi,
Thanks for reporting this issue. I see where the panic is occurring. We'll address it as soon as possible

[Didainius]

@Nagte502 ,
Could you enable logging https://registry.terraform.io/providers/vmware/vcd/latest/docs#logging and share the log?
You could double check and obfuscate some data like hostnames, etc if you need to.

We'd like to see the edge gateway structure that is coming from API. The data source did work on a few test cases we have, but obviously yours is more complicated and triggers this error.

[Nagte502]

See the attached file. I have cleaned some data like names, but kept is as "original" as I could.

ipv6_provider_log_cleaned.txt

[Nagte502]

We suspect it has to do with the edgeGatewayUplinks (all the way down in the log), where one of the subnets has ipv6 ranges. (gateway, start and end address). When removing those from the edge, all seems to work just fine :)

[Didainius]

Yeah,
So VCD API does not return totalIpCount when there is a big IPv6 range. We will patch crash. The caveat it looks like that such ranges will not be reflected in IP counts.

[Nagte502]

Ah that's an inconsistency in the VCD API then. Hopefully this is an easy fix for the Terraform code. Will this patch be in the new release or will 3.12 get an update?

[Didainius]

v3.12.1 is released and has a fix for panic. There is a caveat though (which is going to be addressed later on) that if there is a huge IPv6 block - it may lag and/or exhaust memory where the provider is running due to internally trying to count all available IPs in range.

[Nagte502]

Unfortunatelly, the bug hasn't been fixed entirely so it seems (see #1270)