Creating dedicated terraform resources for objects that are managed by the API

[ctreatma]

Creating dedicated terraform resources for objects that are managed by the API

Background

We recently ran into an issue with using the metal_connection resource to manage shared connections. For shared connection, users can specify the vlans attribute in order to attach VLANs to the connection's ports. This is supported via a single call to the create connection API. However, changes to the vlans attribute were silently ignored because the update connection API does not support updating VLANs for a shared connection. We evaluated a few different options for changing the behavior of the metal_connection resource when the vlans attribute is changed, and eventually implemented additional calls from the metal_connection resource to the update virtual circuit API to update VLANs for a terraform-managed shared connection. However, hiding additional logic in our terraform resources in this manner makes our user's terraform configs less explicit.

Managing shared connection VLANs with metal_virtual_circuit

Ultimately, the issue we're running up against for shared metal_connection VLANs is that the API creates hidden virtual circuits (or hidden ports & virtual circuits?) for shared connections, and the API only allows users to manage these hidden virtual circuits via the connection API when a connection is created. After a connection is created, the hidden virtual circuits must be managed with the virtual circuit API.

Instead of managing shared metal_connection VLANs via the metal_connection resource, we could enable customers to manage those VLANs with the metal_virtual_circuit resource, so that network configuration is more consistent between shared & dedicated connections, and so that we are not hiding virtual circuit management in our metal_connection resource.

Dedicated connection VLAN management

[WIP] example of managing VLANs for a dedicated metal connection; I don't know if this reflects reality yet.

resource "metal_connection" "dedicated" {
  # some attributes
  type = "dedicated"
}

resource "metal_virtual_circuit" "dedicated_primary_vlan" {
  port_id = metal_connection.dedicated.ports[0]
  vlan_id = <a_vlan_ref1>
}

resource "metal_virtual_circuit" "dedicated_secondary_vlan" {
  port_id = metal_connection.dedicated.ports[1]
  vlan_id = <a_vlan_ref2>
}

Shared connection VLAN management

With some changes to the metal_virtual_circuit resource, we could use that resource to manage shared connection virtual circuits instead of hiding that logic in the metal_connection resource.

The below HCL example assumes that the metal_virtual_circuit resource gains a new type attribute (could be a behavior instead?). When type is "shared", the metal_virtual_circuit expects the id attribute to be provided. On create, it makes a VCUpdateRequest instead of VCCreateRequest, passing the vlan_id/vnid specified in the configuration. On delete, it makes a VCUpdateRequest instead of VCDeleteRequest, passing "" as the vlan_id/vnid.

While this is more verbose than hiding the shared virtual circuit logic in the metal_connection resource, it is also more explicit/intentional, and it more closely matches the reality of how these hidden virtual circuits are managed. In the web UI, for example, you can only change shared connection VLANs one at a time, and swapping VLANs requires at least 3 button clicks.

resource "metal_connection" "shared" {
  # some attributes
  type = "shared"
}

resource "metal_virtual_circuit" "shared_primary_vlan" {
  id = metal_connection.dedicated.ports[0].virtual_circuits[0].id
  type = "shared"
  vlan_id = <a_vlan_ref1>
}

resource "metal_virtual_circuit" "shared_secondary_vlan" {
  id = metal_connection.dedicated.ports[1].virtual_circuits[0].id
  type = "shared"
  vlan_id = <a_vlan_ref2>
}

[ctreatma]

This was either moved to an issue or duplicated by one (relevant issues look to be #363 and #629). With the introduction of BGP on VRF connections, it became necessary to adopt, roughly, the approach mentioned in this discussion, so that the existing metal_virtual_circuit resource can be used to manage both dedicated and shared virtual circuits.