Forum Discussion
Crossplane - failure to delete port resource in Claim
I am using both Port and PortVlanAttachment because that is how our year+ old terraform script was ensuring that the port was "unbonded" and traffic was tagged. What I really need is to create a device that is unbonded and add a vlan to the eth1 port and ensure that traffic is tagged to this port. We found that adding a second vlan tagged "turned on" the traffic tagging. Is this still the case?
My use case is that I will be attaching a fabric connection to this metal port and need it to be tagged. So the logic now is to:
1) create a vlan, create my nfv (metal device) with an unbonded Eth1 and associate the dummy vlan uuid with the UUID of the Eth1 port.
2) Associate a fabric Vlan with the metal device by creating a 2nd metal vlan, adding that vlan UUID to the same port (to the vlanIds array -this enables tagged traffic) and create a metal connection to associate this vlanUUID with the fabric one.
The problem I see here is that if I do NOT use a portVlanAttachment, then when I want to "offboard" my fabric Vlan I need to edit the Spec of the "Port" instead of just deleting the portVlanAttachment associated with the fabric onboarding. This is harder for me and not directly supported in any Crossplane composition. Perhaps the data models are not ideal here?
When I create the Port in the first place, I do not add a Vlan ID (tag or UUID). I let the portVlanAttachment object do that, so it seems that internally there is a conflict between the uuid and tag.
> What I really need is to create a device that is unbonded and add a vlan to the eth1 port and ensure that traffic is tagged to this port. We found that adding a second vlan tagged "turned on" the traffic tagging. Is this still the case?
See the general overview in the docs for the network mode of your port configuration (https://deploy.equinix.com/developers/docs/metal/layer2-networking/).
Generally, if only one VLAN exists, it will be made the native (untagged) VLAN. Adding additional VLANs and denoting one of these as the `nativeVlanId` (or using the Ref/Selector fields) will ensure that the other VLANs are tagged. (https://marketplace.upbound.io/providers/equinix/provider-jet-equinix/v0.6.1/resources/metal.equinix.jet.crossplane.io/Port/v1alpha1).
If your additional VLANs may be deleted later, this would toggle the last remaining VLAN to become a Native VLAN. You may want to include an extra VLAN to act as a persistent native VLAN to prevent that.
Editing the Port spec, to modify the list of VLANs to remove a Fabric connected VLAN should be composable. Removing VLANs will update the resource in place and not destroy the resource or change the network mode unless explicitly changed.
The Port resource's VLAN fields are vlanIds or vxlandIds. Unlike nativeVlanIds, I see that the provider doesn't offer Ref and Selector variations for the vlanIds and vxlanIds fields. That could certainly be improved.
For full automation, where the device may also be destroyed, you may want to use the resetOnDelete flag so that VLANs and Ports can be deleted without dependency issues (prevent problems where a vlan can not be deleted because a port is bound to it).
Featured Places
Discussions
Engage with industry experts, share insights, ask questions, and grow your network.Ideas
We're listening! Submit your ideas to shape the future of Equinix!Groups
Ready to collaborate? Join a Group or upcoming beta program.What's New
Stay ahead with the latest from Equinix. Discover new product announcements, insightful tutorials, and practical use cases.Events
Your Guide to Upcoming Events - Online, Hybrid, and In-Person!
