Error creating NetworkInterfaceBackendAddressPoolAssociation

[prfj]

What happened?

Unable to create a NetworkInterfaceBackendAddressPoolAssociation this prevents from adding LinuxVirtualMachines and WindowsVirtualMachines into a Loadbalancer.

How can we reproduce it?

apiVersion: network.azure.upbound.io/v1beta1
kind: NetworkInterfaceBackendAddressPoolAssociation
metadata:
  name: my-nic-lb-association
spec:
  forProvider:
    backendAddressPoolId: >-
      <ID-OF-A-ILB-BACKEND-ADDRESS-POOL>
    ipConfigurationName: <NAME-OF-VM-IPCONFIGURATION>
    networkInterfaceId: >-
     <ID-OF-VM-NIC>

After applying this manifest, resource is NOT created on provider and have the error

observe failed: cannot run refresh: refresh failed: Expected ID to be in
        the format
        {networkInterfaceId}/ipConfigurations/{ipConfigurationName}|{backendAddressPoolId}
        but got "my-nic-lb-association": 

What environment did it happen in?

• Crossplane Version: 1.12.1
• Provider Version: v0.34.0
• Kubernetes Version: v1.24.10
• Kubernetes Distribution: AKS

[turkenf]

Hi @prfj,

Thank you for raising this issue but I could not reproduce the issue. There seems to be an issue with the ids of the arguments you are using. Could you please make sure it is in the following format and try again?

apiVersion: network.azure.upbound.io/v1beta1
kind: NetworkInterfaceBackendAddressPoolAssociation
metadata:
  name: example
spec:
  forProvider:
    # The ID of the Load Balancer Backend Address Pool which this Network Interface should be connected to.
    backendAddressPoolId: /subscriptions/01232b7c-1234-1234-1234-12341a341234/resourceGroups/example/providers/Microsoft.Network/loadBalancers/example/backendAddressPools/example
    ipConfigurationName: testconfiguration1
    # The ID of the Network Interface.
    networkInterfaceId: /subscriptions/0123b7c-1234-1234-1234-c1a12dv41234/resourceGroups/example/providers/Microsoft.Network/networkInterfaces/example

[prfj]

Hi @turkenf, thanks for response,

I just confirmed again, the networkInterfaceId / ipConfigurationName / backendAddressPoolId i am using are valid and I still get same issue.

Maybe I didn't explained well, I am able to run the k apply with success, but after apply if i k describe the resource it will appear the error and it never gets created on cloud provider

Can you confirm that in your tests this behavior don't happen ?

[turkenf]

Yes @prfj, I have successfully created the NetworkInterfaceBackendAddressPoolAssociation resource. The conditions are below:

status:
  atProvider:
    backendAddressPoolId: /subscriptions/01232b7c-1234-1234-1234-12341a341234/resourceGroups/example/providers/Microsoft.Network/loadBalancers/example/backendAddressPools/example
    id: /subscriptions/01232b7c-1234-1234-1234-12341a341234/resourceGroups/example/providers/Microsoft.Network/networkInterfaces/example/ipConfigurations/testconfiguration1|/subscriptions/01232b7c-1234-1234-1234-12341a341234/resourceGroups/example/providers/Microsoft.Network/loadBalancers/example/backendAddressPools/example
    ipConfigurationName: testconfiguration1
    networkInterfaceId: /subscriptions/01232b7c-1234-1234-1234-12341a341234/resourceGroups/example/providers/Microsoft.Network/networkInterfaces/example
  conditions:
  - lastTransitionTime: "2023-07-06T10:07:53Z"
    reason: ReconcileSuccess
    status: "True"
    type: Synced
  - lastTransitionTime: "2023-07-06T10:09:07Z"
    reason: Available
    status: "True"
    type: Ready
  - lastTransitionTime: "2023-07-06T10:08:15Z"
    reason: Success
    status: "True"
    type: LastAsyncOperation
  - lastTransitionTime: "2023-07-06T10:08:15Z"
    reason: Finished
    status: "True"
    type: AsyncOperation

Can you please try the attached example?
reproduce 3.yaml.zip
I think this example will work(it works in mine), you can find the problem by comparing it with your own example using the command kubectl get networkinterfacebackendaddresspoolassociation.network.azure.upbound.io/example -o yaml or kubectl describe .....

[prfj]

Hi @turkenf

After doing more tests now i've reached a conclusion...

This is only happening if external-name is defined on the NetworkInterfaceBackendAddressPoolAssociation resource

kind: NetworkInterfaceBackendAddressPoolAssociation
...
metadata:
  name: vm-nic-lbassociation
  annotations:
    crossplane.io/external-name: vm-nic-lbassociation

this will fail

kind: NetworkInterfaceBackendAddressPoolAssociation
...
metadata:
  name: vm-nic-lbassociation

this will work

[prfj]

Hey @turkenf

any news on this is now identified as issue or its normal behavior ?

[turkenf]

@prfj yes, this is expected behavior because the external name configuration for this resource is IdentifierFromProvider. This means the external name annotation becomes the Terraform ID directly without any transformations/normalizations. So the expected syntax for the external name annotation is what the Terraform documentation says. Therefore, the use of the string vm-nic-lbassociation does not match the expected syntax, leading to the issue you encountered.

[prfj]

@turkenf thanks

I will close this issue

TLDR: for NetworkInterfaceBackendAddressPoolAssociation don't set metadata.annotations['crossplane.io/external-name']