`d/vsphere_network` errors if networks of different types use the same name

[skevir]

Description

I am working with a vSphere set-up in which there is a standard (host-based) port group and a DVS port group that both have the same name. Thus trying to create a vsphere_network data object fails with the following error:

error fetching network: path 'myPortGroup' resolves to multiple networks, Please specify

Here's the vsphere_network data object from the Terraform file:

data "vsphere_network" "my_port_group" {
  datacenter_id = data.vsphere_datacenter.dc.id
  name          = "myPortGroup"
}

I'm trying to get the standard port group, so it would be really useful to be able to specify the type in the above to be able to indicate which type of network I am interested in.

This looks related to the change that was made by this pull request: https://github.com/hashicorp/terraform-provider-vsphere/pull/1001 - for differentiating between DVS port groups with the same name where a distributed_virtual_switch_uuid argument was added.

Does such a change sound sensible? Or am I missing something and there is already a way I could disambiguate the two port groups?

Potential Terraform Configuration

data "vsphere_network" "my_port_group" {
  datacenter_id = data.vsphere_datacenter.dc.id
  name          = "myPortGroup"
  type            = "<type of network>"
}

where type of network is one of "DistributedVirtualPortgroup", "Network" or "OpaqueNetwork".

References

https://github.com/hashicorp/terraform-provider-vsphere/issues/925

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

[codeopen1]

I think a better approach, in my opinion, would be to split out the vsphere_network data resource in to 3 separate ones:

• vsphere_distributed_port_group
• vsphere_host_port_group
• vsphere_opaque_network

I'd also suggest adding a data resource for vsphere_host_port_group (there is already one for DVS).

That would bring the network data resources into line with the regular resource types + an extra one for opaque networks. This would give more information to the user and greater flexibility.

Looking at the docs, Network is a managed object extended by DistributedVirtualPortgroup and OpaqueNetwork [1] and HostPortGroup is just a data object [2]. I think it makes sense to expose the most specific objects to the user instead of the higher-level ones.

Thoughts?

I'd be happy to take a look at this as part of #1145

Edit - It looks like the HostOpaqueNetworkInfo [3] might be a more complete model for an vsphere_opaque_network data resource.

[1] - https://vdc-download.vmware.com/vmwb-repository/dcr-public/b50dcbbf-051d-4204-a3e7-e1b618c1e384/538cf2ec-b34f-4bae-a332-3820ef9e7773/vim.Network.html [2] - https://vdc-download.vmware.com/vmwb-repository/dcr-public/b50dcbbf-051d-4204-a3e7-e1b618c1e384/538cf2ec-b34f-4bae-a332-3820ef9e7773/vim.host.PortGroup.html [3] - https://vdc-download.vmware.com/vmwb-repository/dcr-public/b50dcbbf-051d-4204-a3e7-e1b618c1e384/538cf2ec-b34f-4bae-a332-3820ef9e7773/vim.host.OpaqueNetworkInfo.html

[skevir]

Yes - agreed - that sounds like a sensible approach, although I'm very new to the provider so don't really have a feel for the best architectural way to address this. Others are probably in a better position to provide concrete input.

My first thought was thinking about backwards compatibility, but I believe you are suggesting leaving the current vsphere_network functionality as is, and simply ensuring there are more specific network data resources for each of the potential types, so no concerns there.

[codeopen1]

I don't really have an opinion on the backwards compatibility but I would hazard a guess that either the existing vsphere_network data resource would stay as an option or get deprecated. I think that's up to the core maintainers but I think the additional functionality and specificity suggested would still be useful.

[bill-rich]

I can see the benefits to both approaches, but I think that it would be better to add the type field to the existing data source. It definitely makes sense looking at the Terraform side of things to make the data sources match the resources, but it does take us further from the workflow in the vSphere client. Let me know if you have further thoughts.

[haydenseitz]

I am having the same issue, where I cannot specify a host-based port group with the same name as a VDS port group. It is possible to specify the distributed port group by using distributed_virtual_switch_uuid when querying for vsphere_network, but not the other way around.