feat: API Sync by GitHub Action (2023-10-12) (#161)

This API Sync PR was automated through [GitHub Actions
workflow_displatch](https://github.com/equinix-labs/metal-go/actions?query=event%3Aworkflow_dispatch)
on 2023-10-12.

* latest Swagger is fetched
* patches have been applied
* generated client has been updated

---------

Co-authored-by: github-actions[bot] <[email protected]>

equinix-openapi-metal/api/openapi.yaml

@@ -23710,17 +23710,7 @@ components:
           format: date-time
           type: string
       required:
-      - bill
-      - description
-      - id
-      - name
-      - nni_vlan
-      - port
-      - project
-      - status
-      - tags
       - virtual_network
-      - vnid
       type: object
     VlanVirtualCircuitCreateInput:
       properties:
@@ -27812,6 +27802,8 @@ components:
         updated_at:
           format: date-time
           type: string
+      required:
+      - vrf
       type: object
     VrfVirtualCircuitCreateInput:
       properties:

equinix-openapi-metal/docs/VirtualCircuit.md

@@ -7,26 +7,26 @@
 
 | Name | Type | Description | Notes |
 |------------ | ------------- | ------------- | -------------|
-|**bill** | **Boolean** | True if the Virtual Circuit is being billed. Currently, only Virtual Circuits of Fabric VCs (Metal Billed) will be billed. Usage will start the first time the Virtual Circuit becomes active, and will not stop until it is deleted from Metal. |  |
-|**description** | **String** |  |  |
-|**id** | **UUID** |  |  |
-|**name** | **String** |  |  |
-|**nniVlan** | **Integer** |  |  |
-|**port** | [**Href**](Href.md) |  |  |
-|**project** | [**Href**](Href.md) |  |  |
+|**bill** | **Boolean** | True if the Virtual Circuit is being billed. Currently, only Virtual Circuits of Fabric VCs (Metal Billed) will be billed. Usage will start the first time the Virtual Circuit becomes active, and will not stop until it is deleted from Metal. |  [optional] |
+|**description** | **String** |  |  [optional] |
+|**id** | **UUID** |  |  [optional] |
+|**name** | **String** |  |  [optional] |
+|**nniVlan** | **Integer** |  |  [optional] |
+|**port** | [**Href**](Href.md) |  |  [optional] |
+|**project** | [**Href**](Href.md) |  |  [optional] |
 |**speed** | **Integer** | integer representing bps speed |  [optional] |
-|**status** | [**StatusEnum**](#StatusEnum) | The status changes of a VRF virtual circuit are generally the same as Virtual Circuits that aren't in a VRF. However, for VRF Virtual Circuits on Fabric VCs, the status will change to 'waiting_on_peering_details' once the Fabric service token associated with the virtual circuit has been redeemed on Fabric, and Metal has found the associated Fabric connection. At this point, users can update the subnet, MD5 password, customer IP and/or metal IP accordingly. For VRF Virtual Circuits on Dedicated Ports, we require all peering details to be set on creation of a VRF Virtual Circuit. The status will change to `changing_peering_details` whenever an active VRF Virtual Circuit has any of its peering details updated. |  |
-|**tags** | **List<String>** |  |  |
+|**status** | [**StatusEnum**](#StatusEnum) | The status changes of a VRF virtual circuit are generally the same as Virtual Circuits that aren't in a VRF. However, for VRF Virtual Circuits on Fabric VCs, the status will change to 'waiting_on_peering_details' once the Fabric service token associated with the virtual circuit has been redeemed on Fabric, and Metal has found the associated Fabric connection. At this point, users can update the subnet, MD5 password, customer IP and/or metal IP accordingly. For VRF Virtual Circuits on Dedicated Ports, we require all peering details to be set on creation of a VRF Virtual Circuit. The status will change to `changing_peering_details` whenever an active VRF Virtual Circuit has any of its peering details updated. |  [optional] |
+|**tags** | **List<String>** |  |  [optional] |
 |**virtualNetwork** | [**Href**](Href.md) |  |  |
-|**vnid** | **Integer** |  |  |
+|**vnid** | **Integer** |  |  [optional] |
 |**createdAt** | **OffsetDateTime** |  |  [optional] |
 |**updatedAt** | **OffsetDateTime** |  |  [optional] |
 |**customerIp** | **String** | An IP address from the subnet that will be used on the Customer side. This parameter is optional, but if supplied, we will use the other usable IP address in the subnet as the Metal IP. By default, the last usable IP address in the subnet will be used. |  [optional] |
 |**md5** | **String** | The MD5 password for the BGP peering in plaintext (not a checksum). |  [optional] |
 |**metalIp** | **String** | An IP address from the subnet that will be used on the Metal side. This parameter is optional, but if supplied, we will use the other usable IP address in the subnet as the Customer IP. By default, the first usable IP address in the subnet will be used. |  [optional] |
 |**peerAsn** | **Integer** | The peer ASN that will be used with the VRF on the Virtual Circuit. |  [optional] |
 |**subnet** | **String** | The /30 or /31 subnet of one of the VRF IP Blocks that will be used with the VRF for the Virtual Circuit. This subnet does not have to be an existing VRF IP reservation, as we will create the VRF IP reservation on creation if it does not exist. The Metal IP and Customer IP must be IPs from this subnet. For /30 subnets, the network and broadcast IPs cannot be used as the Metal or Customer IP. |  [optional] |
-|**vrf** | [**Vrf**](Vrf.md) |  |  [optional] |
+|**vrf** | [**Vrf**](Vrf.md) |  |  |
 
 
 

equinix-openapi-metal/docs/VlanVirtualCircuit.md

@@ -7,18 +7,18 @@
 
 | Name | Type | Description | Notes |
 |------------ | ------------- | ------------- | -------------|
-|**bill** | **Boolean** | True if the Virtual Circuit is being billed. Currently, only Virtual Circuits of Fabric VCs (Metal Billed) will be billed. Usage will start the first time the Virtual Circuit becomes active, and will not stop until it is deleted from Metal. |  |
-|**description** | **String** |  |  |
-|**id** | **UUID** |  |  |
-|**name** | **String** |  |  |
-|**nniVlan** | **Integer** |  |  |
-|**port** | [**Href**](Href.md) |  |  |
-|**project** | [**Href**](Href.md) |  |  |
+|**bill** | **Boolean** | True if the Virtual Circuit is being billed. Currently, only Virtual Circuits of Fabric VCs (Metal Billed) will be billed. Usage will start the first time the Virtual Circuit becomes active, and will not stop until it is deleted from Metal. |  [optional] |
+|**description** | **String** |  |  [optional] |
+|**id** | **UUID** |  |  [optional] |
+|**name** | **String** |  |  [optional] |
+|**nniVlan** | **Integer** |  |  [optional] |
+|**port** | [**Href**](Href.md) |  |  [optional] |
+|**project** | [**Href**](Href.md) |  |  [optional] |
 |**speed** | **Integer** | For Virtual Circuits on shared and dedicated connections, this speed should match the one set on their Interconnection Ports. For Virtual Circuits on Fabric VCs (both Metal and Fabric Billed) that have found their corresponding Fabric connection, this is the actual speed of the interconnection that was configured when setting up the interconnection on the Fabric Portal. Details on Fabric VCs are included in the specification as a developer preview and is generally unavailable. Please contact our Support team for more details. |  [optional] |
-|**status** | [**StatusEnum**](#StatusEnum) | The status of a Virtual Circuit is always 'pending' on creation. The status can turn to 'Waiting on Customer VLAN' if a Metro VLAN was not set yet on the Virtual Circuit and is the last step needed for full activation. For Dedicated interconnections, as long as the Dedicated Port has been associated to the Virtual Circuit and a NNI VNID has been set, it will turn to 'waiting_on_customer_vlan'. For Fabric VCs, it will only change to 'waiting_on_customer_vlan' once the corresponding Fabric connection has been found on the Fabric side. If the Fabric service token associated with the Virtual Circuit hasn't been redeemed on Fabric within the expiry time, it will change to an `expired` status. Once a Metro VLAN is set on the Virtual Circuit (which for Fabric VCs, can be set on creation of a Fabric VC) and the necessary set up is done, it will turn into 'Activating' status as it tries to activate the Virtual Circuit. Once the Virtual Circuit fully activates and is configured on the switch, it will turn to staus 'active'. For Fabric VCs (Metal Billed), we will start billing the moment the status of the Virtual Circuit turns to 'active'. If there are any changes to the VLAN after the Virtual Circuit is in an 'active' status, the status will show 'changing_vlan' if a new VLAN has been provided, or 'deactivating' if we are removing the VLAN. When a deletion request is issued for the Virtual Circuit, it will move to a 'deleting' status, and we will immediately unconfigure the switch for the Virtual Circuit and issue a deletion on any associated Fabric connections. Any associated Metro VLANs on the virtual circuit will also be unassociated after the switch has been successfully unconfigured. If there are any associated Fabric connections, we will only fully delete the Virtual Circuit once we have checked that the Fabric connection was fully deprovisioned on Fabric. |  |
-|**tags** | **List<String>** |  |  |
+|**status** | [**StatusEnum**](#StatusEnum) | The status of a Virtual Circuit is always 'pending' on creation. The status can turn to 'Waiting on Customer VLAN' if a Metro VLAN was not set yet on the Virtual Circuit and is the last step needed for full activation. For Dedicated interconnections, as long as the Dedicated Port has been associated to the Virtual Circuit and a NNI VNID has been set, it will turn to 'waiting_on_customer_vlan'. For Fabric VCs, it will only change to 'waiting_on_customer_vlan' once the corresponding Fabric connection has been found on the Fabric side. If the Fabric service token associated with the Virtual Circuit hasn't been redeemed on Fabric within the expiry time, it will change to an `expired` status. Once a Metro VLAN is set on the Virtual Circuit (which for Fabric VCs, can be set on creation of a Fabric VC) and the necessary set up is done, it will turn into 'Activating' status as it tries to activate the Virtual Circuit. Once the Virtual Circuit fully activates and is configured on the switch, it will turn to staus 'active'. For Fabric VCs (Metal Billed), we will start billing the moment the status of the Virtual Circuit turns to 'active'. If there are any changes to the VLAN after the Virtual Circuit is in an 'active' status, the status will show 'changing_vlan' if a new VLAN has been provided, or 'deactivating' if we are removing the VLAN. When a deletion request is issued for the Virtual Circuit, it will move to a 'deleting' status, and we will immediately unconfigure the switch for the Virtual Circuit and issue a deletion on any associated Fabric connections. Any associated Metro VLANs on the virtual circuit will also be unassociated after the switch has been successfully unconfigured. If there are any associated Fabric connections, we will only fully delete the Virtual Circuit once we have checked that the Fabric connection was fully deprovisioned on Fabric. |  [optional] |
+|**tags** | **List<String>** |  |  [optional] |
 |**virtualNetwork** | [**Href**](Href.md) |  |  |
-|**vnid** | **Integer** |  |  |
+|**vnid** | **Integer** |  |  [optional] |
 |**createdAt** | **OffsetDateTime** |  |  [optional] |
 |**updatedAt** | **OffsetDateTime** |  |  [optional] |
 

equinix-openapi-metal/docs/VrfVirtualCircuit.md

@@ -21,7 +21,7 @@
 |**status** | [**StatusEnum**](#StatusEnum) | The status changes of a VRF virtual circuit are generally the same as Virtual Circuits that aren't in a VRF. However, for VRF Virtual Circuits on Fabric VCs, the status will change to 'waiting_on_peering_details' once the Fabric service token associated with the virtual circuit has been redeemed on Fabric, and Metal has found the associated Fabric connection. At this point, users can update the subnet, MD5 password, customer IP and/or metal IP accordingly. For VRF Virtual Circuits on Dedicated Ports, we require all peering details to be set on creation of a VRF Virtual Circuit. The status will change to `changing_peering_details` whenever an active VRF Virtual Circuit has any of its peering details updated. |  [optional] |
 |**subnet** | **String** | The /30 or /31 subnet of one of the VRF IP Blocks that will be used with the VRF for the Virtual Circuit. This subnet does not have to be an existing VRF IP reservation, as we will create the VRF IP reservation on creation if it does not exist. The Metal IP and Customer IP must be IPs from this subnet. For /30 subnets, the network and broadcast IPs cannot be used as the Metal or Customer IP. |  [optional] |
 |**tags** | **List<String>** |  |  [optional] |
-|**vrf** | [**Vrf**](Vrf.md) |  |  [optional] |
+|**vrf** | [**Vrf**](Vrf.md) |  |  |
 |**createdAt** | **OffsetDateTime** |  |  [optional] |
 |**updatedAt** | **OffsetDateTime** |  |  [optional] |