ContributionsMost RecentMost LikesSolutionsRe: Crossplane - failure to delete port resource in Claim 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. Re: Crossplane - failure to delete port resource in Claim 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. Crossplane - Metal Vlan description not updated in UI When editing an existing Metal Vlan resource's spec to add a description, the string is applied to the managed resource but is not updated in the UI. If the description is included in the original Vlan resource spec during creation, the UI shows the description. apiVersion: metal.equinix.jet.crossplane.io/v1alpha1 kind: Vlan metadata: name: myvlan1 spec: forProvider: description: | Dummy native VLAN for purposes of enabling tagging on the trunk port. projectId: <uuid> metro: sv If the spec.forProvider.description is left out during the creation, then editing the resource and applying the change will not cause the description to show up in the UI. I'm not sure if this is expected or not. Re: 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. 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 Metal provider - lifecycle.prevent_destroy error After I spin up a Metal Device using the Crossplane Equinix provider, it comes up but in the events I see the following. I'm not sure if it is expected or a bug? Managed resource event message: Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal CreatedExternalResource 3m7s managed/metal.equinix.jet.crossplane.io/v1alpha1, kind=device Successfully requested creation of external resource Warning CannotObserveExternalResource 13s (x6 over 30s) managed/metal.equinix.jet.crossplane.io/v1alpha1, kind=device cannot run plan: plan failed: Instance cannot be destroyed: Resource equinix_metal_device.my-gateway-sv-4x2x4-4gfpq has lifecycle.prevent_destroy set, but the plan calls for this resource to be destroyed. To avoid this error and continue with the plan, either disable lifecycle.prevent_destroy or reduce the scope of the plan using the -target flag. Field in XRD for plan is: "plan: m3.small.x86" Environment: Crossplane v1.16 Equinix Provider: v0.6.1 K8s: Kind 1.27 Re: Trouble updating Crossplane Claim status with Equinix Provider Looks like the error may have been related to some typos in my composition/definition yaml files. The Crossplane linter could not catch these specific ones, but after refactoring both these files I do now see the xrd status fields being populated with the right info. Thanks Marques. These crossplane providers are invaluable and I hope more development can occur so we can better integrate with Equinix. Trouble updating Crossplane Claim status with Equinix Provider I’m having some trouble using the Equinix providers within a Claim and I’m not sure where the problem lies. The issue is that I am trying to take the ID uuid from the Devicestatus.atProvider.idand update astatus.idfield in my xrd claim, but the status never seems to get updated. This works fine with the AWS provider as an example. In my example I want to grab the UUID of the device and populate the Claim XRD's status.id field, but I do not see this population happening. I use the same technique with the upbound AWS provider so I know it is valid. Within the composition.yaml: - type: ToCompositeFieldPath fromFieldPath: status.atProvider.id toFieldPath: status.id Has anyone else gotten this to work?