Forum Discussion

mmellin's avatar
mmellin
Level 3
4 months ago

Crossplane - failure to delete port resource in Claim

I have created a Claim that includes a Device, Port, PortVlanAttachment and a Vlan. In order to create the Port I have to pass the Device Eth1 port UUID to the 'spec.forProvider.portId' of the Port Kind. This works and picks up the vlan info, but upon deleting the claim, the port is not deleted automatically as expected. The following event messages can be seen:

 

Conflicting configuration arguments: "vlan_ids": conflicts with vxlan_ids
Warning CannotObserveExternalResource 8s (x10 over 6m27s) managed/metal.equinix.jet.crossplane.io/v1alpha1, kind=port cannot run refresh: refresh failed: Conflicting configuration arguments: "vlan_ids": conflicts with vxlan_ids
Conflicting configuration arguments: "vxlan_ids": conflicts with vlan_ids

 

The spec of the object looks like this:

 

 

Spec:
  Deletion Policy:  Delete
  For Provider:
    Bonded:   false
    Port Id:  b561e487-fbb0-4a2c-98e7-22da331ed316
    Vlan Ids:
      73f648b5-9b6b-4076-a6ab-673aa45c7152
    Vxlan Ids:
      1000
  Provider Config Ref:
    Name:  default

 

 

In order to resolve the issue I need to manually delete the resources finalizer. 

crossplane
Equinix Metal
    • mmellin's avatar
      mmellin
      Level 3
      3 months ago

      I'm definitely hitting this issue. I cannot tell if that is the reason for the following issue:

      I can use a "Port" resource to "attach" a first vlan to the Device, but subsequent vlans added to the spec.forProvider.vlanIds array are not added to the Device. The message that shows in the condition is:

      Message:               observe failed: cannot run refresh: refresh failed: Conflicting configuration arguments: "vlan_ids": conflicts with vxlan_ids
Conflicting configuration arguments: "vxlan_ids": conflicts with vlan_ids

      Looking at the spec after this, the Port resource looks like this (not two UUIDs but only one Vxlan ID tag:

      For Provider:
    Bonded:           false
    Port Id:          d07bd18c-641a-4f87-9d5b-b7ab1f9d2ec2
    Reset On Delete:  true
    Vlan Ids:
      0d0f0d89-a54c-42eb-b16a-0630fe9b4159
      22597c24-ac4e-4e0e-8802-16defe95deaa
    Vxlan Ids:
      1000

      The UI (Networking > VLANS) shows only the first Vlan attached to a device, the other shows as 0. 

      To be clear, here I am NOT using a portVlanAttachment - only Port as you've suggested. It looks as though I cannot add multiple vlans using this approach. I will try with portVlanAttachment and see if behavior is different.

      • mmellin's avatar
        mmellin
        Level 3
        3 months ago

        Using only a portVlanAttachment (and not a port) also does not work. I think this might be a bug? The condition event says this:

            Last Transition Time:  2024-07-17T00:47:06Z
    Message:               apply failed: POST https://api.equinix.com/metal/v1/ports/c6b1b719-5ea7-4509-8ede-ee46b05ce4d5/assign: 422 still bonded : 
    Reason:                ApplyFailure
    Status:                False
    Type:                  LastAsyncOperation

        My resource definition looks like this:

        ---
apiVersion: metal.equinix.jet.crossplane.io/v1alpha1
kind: PortVlanAttachment
metadata:
  name: mmellinproj-equinix-sv-v1000
spec:
  forProvider:
    deviceIdSelector:
      matchLabels:
        jci.jnpr.net/equinix: device
    forceBond: False
    portName: eth1
    vlanVnid: 1000

        It seems that the unbonding only occurs when a "Port" resource is created, although it is clearly specified here in the API. Then to attach vlans I must use a PortVlanAttachment. No other combination has been successful for me.

  • mmellin's avatar
    mmellin
    Level 3
    3 months ago

    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.

     

    • Marques's avatar
      Marques
      Equinix Employee
      3 months ago

      > 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).

  • Marques's avatar
    Marques
    Equinix Employee
    4 months ago

    `PortVlanAttachment` shouldn't be needed if you have a `Port` resource. `Port` is preferable as it can be used to toggle the port's layer 2/3 settings, bonding, and VLAN attachments in one shot.

    In the `Port` resource, you should only define `vlanIds` referencing the `.id` (UUID) of the `Vlan` resources. The `vxlanIds` field (and its API upstream equivalent) is for convenience and allows you to reference the VLANs by logical number (1000, 1001). Specifying both would trigger a conflict.

    If you are already doing that, and have removed any `Port` redundant `PortVlanAttachment` resources and still getting this error, then we may have another example of https://github.com/crossplane-contrib/provider-jet-equinix/issues/50#issuecomment-2223332204, where conflicting parameters are LateInitialized from their computed values (the `Port` `vlanIds`, as read from the Equinix Metal API response, could be getting updated automatically in `spec` by the provider, creating the conflict).

    If so, please open an issue on the repo.