Add support for defining DVSwitch PVLAN mappings as an independent resource

[GCHQDeveloper609]

Community Guidelines

• [X] I have read and agree to the HashiCorp Community Guidelines .
• [X] Vote on this issue by adding a 👍 reaction to the original issue initial description to help the maintainers prioritize.
• [X] Do not leave "+1" or other comments that do not add relevant information or questions.
• [X] If you are interested in working on this issue or have submitted a pull request, please leave a comment.

Description

Provide an independent resource for creating a PVLAN Mapping entry on a VMWare Distributed Virtual Switch. This would work similarly to - and follow the good example set by - the AWS provider resource vpc_security_group_ingress_rule where it would be mutually exclusive with directly specifying the mappings on the distributed_virtual_switch object.

There is already an ignore_other_pvlan_mappings attribute on a distributed virtual switch which would complement this functionality.

Use Case(s)

For environments where only one distributed virtual switch is available, managing the mappings from just one Terraform root module containing the distributed_virtual_switch resource is cumbersome. For example, if you wish to deploy a production and staging version of an application onto the same distributed_virtual_switch, the current best way to achieve this would be to manually create the mappings, or manage them from a third root module dedicated just to the DVSwitch.

With a resource to allow the definition of individual mappings, it would allow a Terraform root module that looks like the following:

data "vsphere_distributed_virtual_switch" "vds" {
  ...
}

resource "vsphere_distributed_virtual_switch_pvlan_mapping" "promiscuous" {
  name                            = "my-application-P"
  distributed_virtual_switch_uuid = data.vsphere_distributed_virtual_switch.vds.id
  primary_vlan_id                 = var.vlans.promiscuous
  secondary_vlan_id               = var.vlans.promiscuous
  pvlan_type                      = "promiscuous"
}

resource "vsphere_distributed_virtual_switch_pvlan_mapping" "isolated" {
  name                            = "my-application-I"
  distributed_virtual_switch_uuid = data.vsphere_distributed_virtual_switch.vds.id
  primary_vlan_id                 = var.vlans.promiscuous
  secondary_vlan_id               = var.vlans.isolated
  pvlan_type                      = "isolated"
}
resource "vsphere_distributed_port_group" "promiscuous" {
  ...
  port_private_secondary_vlan_id = vsphere_distributed_virtual_switch_pvlan_mapping.promiscuous.secondary_vlan_id
}

resource "vsphere_distributed_port_group" "isolated" {
  ...
  port_private_secondary_vlan_id = vsphere_distributed_virtual_switch_pvlan_mapping.isolated.secondary_vlan_id
}

resource "vsphere_virtual_machine" "primary_host" {
  ...
  network_interface {
    network_id = vsphere_distributed_port_group.promiscuous.id
  }
}

resource "vsphere_virtual_machine" "secondary_hosts" {
  count = 10
  ...
  network_interface {
    network_id = vsphere_distributed_port_group.isolated.id
  }
}

This root module could then be deployed multiple times, with each project being responsible for just it's own PVLAN mappings, rather than one resource responsible for ALL mappings on the switch.

Potential Terraform Provider Configuration

No response

References

No response

[github-actions[bot]]

Hello, GCHQDeveloper609! 🖐

Thank you for submitting an issue for this provider. The issue will now enter into the issue lifecycle.

If you want to contribute to this project, please review the contributing guidelines and information on submitting pull requests.

[GCHQDeveloper609]

I've already got a prototype of this working and will create a pull request with it once I've had some time to clean it up a little, but thought I'd make this in the meantime to gauge interest and whether the team think this is a feature they'd be willing to support.