vra_network datasource failing since v0.12

[PaulAngus]

Code of Conduct

This project has a Code of Conduct that all participants are expected to understand and follow:

• I have read and agree to the project's Code of Conduct

vRA Version

v0.12

Terraform Version

v1.10.2

vRA Terraform Provider Version

v0.12

Affected Resource(s)

v8.18.1

Terraform Configuration Files

data "vra_network" "net1" {
  name = var.networkname
}

resource "vra_machine" "vm1" {
  name          = var.vm_name
  description   = var.vm_description
  project_id    = data.vra_project.project.id
  image         = var.image_name
  flavor        = var.flavor_name
  deployment_id = resource.vra_deployment.deployment.id
  nics {
    network_id = data.vra_network.net1.id
  }
}

Expected Behavior

terraform plan executes successfully

Actual Behavior

Error thrown:

Error: there are more than one network with name 'network-xyz'

Steps to Reproduce

Run terraform plan referencing "name = var.networkname"

Screenshots

Panic Output

Important Factoids

Referring to the network by name has worked in all versions up until v0.12.
We use NSX(T), previously the provider returned the ID of the NSX segment. Now it appears to be returning all of the dvSwitch portgroups that NSX created (which is one per cluster) as well as the NSX segment.

References

Debug Output

"@level":"info",
"@message":"2025/03/13 10:34:19 {"content":[{"projectId":"401fbe61-8252-4fb1-afd9-4f9b5e74a77e",
"externalRegionId":"global",
"cloudAccountIds":["d1853f1a-9b1d-4383-a662-1e49c94df1b8"],
"deploymentId":"e4957282-99aa-431c-804d-e6015a8e5a96",
"tags":[{"key":"Region",
"value":"lon0"},
{"key":"NetworkCIDR",
"value":"172.16.2.0/24"},
{"key":"PrimaryNetworkCIDR",
"value":"172.16.2.0/24"},
{"key":"region",
"value":"lon1"}],
"customProperties":{"path":"/infra/segments/d304a3d2-384e-4359-9b9c-57089ad4f216",
"vlanIds":"1602"},
"externalId":"d304a3d2-384e-4359-9b9c-57089ad4f216",
"name":"network-xyz",
"id":"d7d592b1-c88b-4f3d-a481-572a337fac4f",
"updatedAt":"2025-03-13",
"owner":"admin",
"ownerType":"user",
"organizationId":"2b2c4e84-b8d5-4d07-973f-c5ae54b189aa",
"orgId":"2b2c4e84-b8d5-4d07-973f-c5ae54b189aa",
"_links":{"cloud-accounts":{"hrefs":["/iaas/api/cloud-accounts/d1853f1a-9b1d-4383-a662-1e49c94df1b8"]},
"self":{"href":"/iaas/api/networks/d7d592b1-c88b-4f3d-a481-572a337fac4f"},
"network-domains":{"href":"/iaas/api/network-domains/4fd9dc14-8c0c-4242-8297-b9e48281b0b1"}}},
{"externalRegionId":"global",
"cloudAccountIds":["d1853f1a-9b1d-4383-a662-1e49c94df1b8"],
"tags":[{"key":"Region",
"value":"lon0"},
{"key":"NetworkCIDR",
"value":"172.16.2.0/24"},
{"key":"PrimaryNetworkCIDR",
"value":"172.16.2.0/24"},
{"key":"region",
"value":"lon1"}],
"customProperties":{"vlanIds":"1602"},
"externalId":"d304a3d2-384e-4359-9b9c-57089ad4f216",
"name":"network-xyz",
"id":"3898930a-5267-4a34-88c8-c1ed947ad1cd",
"updatedAt":"2025-03-13",
"organizationId":"2b2c4e84-b8d5-4d07-973f-c5ae54b189aa",
"orgId":"2b2c4e84-b8d5-4d07-973f-c5ae54b189aa",
"_links":{"cloud-accounts":{"hrefs":["/iaas/api/cloud-accounts/d1853f1a-9b1d-4383-a662-1e49c94df1b8"]},
"self":{"href":"/iaas/api/networks/3898930a-5267-4a34-88c8-c1ed947ad1cd"},
"network-domains":{"href":"/iaas/api/network-domains/4fd9dc14-8c0c-4242-8297-b9e48281b0b1"}}}],
"totalElements":2,
"numberOfElements":2}",
"@module":"provider.terraform-provider-vra_v0.12.0",
"@timestamp":"2025-03-13T10:34:19.726676Z",
"timestamp":"2025-03-13T10:34:19.726Z"}
{"@level":"info",
"@message":"2025/03/13 10:34:19 0",
"@module":"provider.terraform-provider-vra_v0.12.0",
"@timestamp":"2025-03-13T10:34:19.726690Z",
"timestamp":"2025-03-13T10:34:19.726Z"}
{"@level":"info",
"@message":"2025/03/13 10:34:19",
"@module":"provider.terraform-provider-vra_v0.12.0",
"@timestamp":"2025-03-13T10:34:19.726697Z",
"timestamp":"2025-03-13T10:34:19.726Z"}
{"@level":"info",
"@message":"2025/03/13 10:34:19",
"@module":"provider.terraform-provider-vra_v0.12.0",
"@timestamp":"2025-03-13T10:34:19.726705Z",
"timestamp":"2025-03-13T10:34:19.726Z"}
{"@level":"info",
"@message":"2025/03/13 10:34:19",
"@module":"provider.terraform-provider-vra_v0.12.0",
"@timestamp":"2025-03-13T10:34:19.726716Z",
"timestamp":"2025-03-13T10:34:19.726Z"}
{"@caller":"github.com/hashicorp/terraform-plugin-sdk/v2@v2.35.0/helper/schema/resource.go:1044",
"@level":"trace",
"@message":"Called downstream",
"@module":"sdk.helper_schema",
"@timestamp":"2025-03-13T10:34:19.726733Z",
"tf_data_source_type":"vra_network",
"tf_provider_addr":"provider",
"tf_req_id":"50051c93-4e7d-f99a-0a94-ad862abda68c",
"tf_rpc":"ReadDataSource",
"timestamp":"2025-03-13T10:34:19.726Z"}
{"@caller":"github.com/hashicorp/terraform-plugin-go@v0.25.0/tfprotov5/internal/tf5serverlogging/downstream_request.go:42",
"@level":"trace",
"@message":"Received downstream response",
"@module":"sdk.proto",
"@timestamp":"2025-03-13T10:34:19.726759Z",
"diagnostic_error_count":1,
"diagnostic_warning_count":0,
"tf_data_source_type":"vra_network",
"tf_proto_version":"5.7",
"tf_provider_addr":"provider",
"tf_req_duration_ms":72,
"tf_req_id":"50051c93-4e7d-f99a-0a94-ad862abda68c",
"tf_rpc":"ReadDataSource",
"timestamp":"2025-03-13T10:34:19.726Z"}
{"@caller":"github.com/hashicorp/terraform-plugin-go@v0.25.0/tfprotov5/internal/diag/diagnostics.go:58",
"@level":"error",
"@message":"Response contains error diagnostic",
"@module":"sdk.proto",
"@timestamp":"2025-03-13T10:34:19.726789Z",
"diagnostic_detail":"",
"diagnostic_severity":"ERROR",
"diagnostic_summary":"there are more than one network with name 'network-xyz'",
"tf_data_source_type":"vra_network",
"tf_proto_version":"5.7",
"tf_provider_addr":"provider",
"tf_req_id":"50051c93-4e7d-f99a-0a94-ad862abda68c",
"tf_rpc":"ReadDataSource",
"timestamp":"2025-03-13T10:34:19.726Z"}
{"@caller":"github.com/hashicorp/terraform-plugin-go@v0.25.0/tfprotov5/tf5server/server.go:705",
"@level":"trace",
"@message":"Served request",
"@module":"sdk.proto",
"@timestamp":"2025-03-13T10:34:19.726807Z",
"tf_data_source_type":"vra_network",
"tf_proto_version":"5.7",
"tf_provider_addr":"provider",
"tf_req_id":"50051c93-4e7d-f99a-0a94-ad862abda68c",
"tf_rpc":"ReadDataSource",
"timestamp":"2025-03-13T10:34:19.726Z"}
{"@level":"error",
"@message":"vertex "data.vra_network.net1" error: there are more than one network with name 'network-xyz'",
"@timestamp":"2025-03-13T10:34:19.727423Z"}
{"@level":"trace",
"@message":"vertex "data.vra_network.net1": visit complete,
 with errors",
"@timestamp":"2025-03-13T10:34:19.727451Z"}
{"@level":"trace",
"@message":"dag/walk: upstream of "root" errored,
 so skipping",
"@timestamp":"2025-03-13T10:34:19.727532Z"}
{"@level":"trace",
"@message":"vertex "data.vra_network.net1 (expand)": dynamic subgraph encountered errors: there are more than one network with name 'network-xyz'",
"@timestamp":"2025-03-13T10:34:19.727620Z"}
{"@level":"error",
"@message":"vertex "data.vra_network.net1 (expand)" error: there are more than one network with name 'network-xyz'",
"@timestamp":"2025-03-13T10:34:19.727627Z"}
{"@level":"trace",
"@message":"vertex "data.vra_network.net1 (expand)": visit complete,
 with errors",
"@timestamp":"2025-03-13T10:34:19.727636Z"}

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

[frodenas]

The issue with previous versions is that the vra_network data source picked the first one returned by the API when multiple networks with the same name existed. This may lead to being unable to choose the desired/correct network. The fact that it used to work for your use case does not guarantee that it will work in the future if the backend changes, for example, the order in which it retrieves the networks.

Starting with v0.12.0, instead of picking the first one, if there are multiple networks with the same name, as you have observed, it returns an error indicating this. To avoid this constraint, a filter parameter has been introduced, which allows filtering by other parameters besides the name. This is in line with the behavior of the other data sources (the fact that we didn't throw an error for this data source in previous versions is a bug).

In your case, we can see two networks with the same name network-xyz. Which one is the one that you want to use for the machine? You must filter the network by other parameters, for example, for the deploymentId or the customProperties.

[PaulAngus]

Hi Ferran,
I've been pulled into other things so I've not had a chance to concentrate in this.
Preliminary testing found that we were still getting multiple results even with the search excluding results with a deploymentID, presumably because all of the vSphere networks and NSX networks have the same properties as the vSphere networks with the same name are just the vSphere portgroup version of the NSX networks. But I need to do more through testing.

A thought - Shouldn't the provider only be looking for networks that are in a Network Profile? The specific instance of network-xyz that we want is the only one with that name that's in a profile.

[frodenas]

The vra_network data source does not have a notion of a network profile; in this case, the backend returns those networks. I have asked internally what is the behavior of the API call that the Terraform provider makes to the AA instance.

[PaulAngus]

I've attached the API command to get the networks with a specific name, and the response.
As you'll see, the networks returned are identical, with the exception of the id of the network. So no filter will work.
Our short-term solution is obviously not to use 0.12, but that's not a sustainable answer to the problem, and that doesn't fix the separate issue of onboarded networks breaking network deployments in <= v0.11

getnetworksapi.txt

[frodenas]

Paul, you may have received this by other channels, have you tried adding (customProperties._ApiAvailable eq 'true') or (customProperties._iaasApi eq 'true') to the filter?

[PaulAngus]

Hi there,
That filter doesn't seem to work either via the Terraform network datasource or using the API directly.
It doesn't return anything.