Network types is now bond instead of device scoped
displague opened this issue · comments
What problem are you facing?
Network types (hybrid, layer2-bonded, layer2-individual, layer3) have always been a computed value used by the Terraform provider and Equinix Metal UI to represent a complex arrangement of port bindings, layer-2 or layer-3 readiness, management address assignments, and vlan attachments.
With recent API and product enhancements, affording more customization of the port configuration, the device-wide single word network type is no longer relevant. This is especially the case for four-port devices, such as n2.x-large (with larger sizes inevitable) where there are multiple bonding pairs. The notion of a bonding pair (with only 2 ports) may also lead to inaccurate representation.
At first glance, it would seem that the scope has shifted to a bond (ethernet pairing) scope. This is not entirely correct and will become less correct in time.
EM offers direct port modification APIs that offer similar functionality regardless of whether the port being affected is a bonding port or an ethernet port.
The most expressive and accurate way to represent port state configuration to users is directly, without a concocted network type that pulls various levers and switches when toggled.
How could the Equinix Metal Crossplane Provider help solve your problem?
A more expressive way to configure the device networking would allow for all ports to be managed independently, with Kubernetes eventually reconciling all of the port states. Ports can be acted on independently of any device or hardware reservation, however, all ports available through the API currently represent either a bonding or ethernet port attached to a user-owned hardware reservation or device instance.
I believe we can reasonably restrict port actions to the scope of a device and do not need independent resources to manage ports. Managing ports independently may be more complicated based on the need to reference the device of the port or the id of the port. On the contrary, in the scope of a device, the port can be referenced easily by a well known, and API guaranteed port name.
I roughly propose the following forProvider spec representation of ports:
forProvider:
plan: "n2.x-large"
ports: # network_ports in the API naming
bond0: # always comprised of ports eth0+eth1 on 2 port devices, or eth0+eth2 on 4 port devices
bonded: true # default
layer2: false # this is default on new devices. changes result in /ports/id/convert/layer-[2|3] API calls
vlans: [1234, 5678, 1234] # shortened this from the API "virtual_networks"
native_vlan: 5678 # optional, must be one of the above if set
ip_addresses:
- reservation_id: uuid # reserved addresses by uuid, may include global ips
- cidr_notation: "1.2.3.4/24" # reserved addresses by address, may include global ips
- type: private_ipv4 # dynamically assigned addresses, available via metadata.platformequinix.net
cidr: 30
bond1: # comprised of port eth1+eth3 on 4 port devices
bonded: false
eth1: # unbonded eth ports can use most of the same attributes bond ports can use
layer2: true
vlans: [7654]
eth3:
layer2: true
vlans: [9876]The atProvider status would include the MAC address, network type (as reported by the API), and id of each port (among other things).
This is related to the following discussions:
Closing for #69
This bespoke representation of the Equinix Metal device networking will not be implemented here.
The capabilities of the Equinix TF provider to represent Metal Device port settings are present in https://github.com/crossplane-contrib/provider-jet-equinix