Bug: Mismatch between HelmReleaseName and AzureName prevents secret creation

[frantisektripsky]

Describe the bug

When creating a NamespacesEventhubsAuthorizationRule resource with a specified Secrets section, and the Helm release name is not equal to the azureName, the following error occurs:
“extension failed to produce resources for export: failed to retreive response: POST https://management.azure.com/subscriptions/my-azure-subscription/resourceGroups/my-azure-resource-group/providers/Microsoft.EventHub/namespaces/my-azure-event-hubs-namespace/eventhubs/my-azure-event-hub/authorizationRules/event-hub-kubernetes-auth-rule/listKeys”
The issue lies in the generated POST URL:
The authorizationRules name in the request (event-hub-kubernetes-auth-rule) incorrectly reflects the Helm release name. It should use the value from azureName instead (event-hub-azure-auth-rule).

The version of the operator pod: v2.10.0

Expected behavior

When creating a NamespacesEventhubsAuthorizationRule resource with a specified Secrets section, if the Helm release name is not equal to the azureName, the following behavior occurs:

a/ The event-hub-azure-auth-rule is created in Azure.
b/ A secret is created in the Kubernetes cluster with an entry named primaryConnectionString.

To Reproduce

Helm release example:
apiVersion: eventhub.azure.com/v1api20211101
kind: NamespacesEventhubsAuthorizationRule
metadata:
name: event-hub-kubernetes-auth-rule
spec:
azureName: event-hub-azure-auth-rule
operatorSpec:
secrets:
primaryConnectionString:
key: primaryConnectionString
name: event-hub- Kubernetes

Screenshots

If applicable, add screenshots to help explain your problem.

Additional context

Add any other context about the problem here.

[matthchr]

You're right, this is a bug. The issue is

azure-service-operator/v2/api/servicebus/customizations/namespaces_authorization_rule_extensions.go

Line 73 in 817462a

response, err := client.ListKeys(ctx, id.ResourceGroupName, namespaceID.Name, rule.Name, &options)

We should be using rule.AzureName() there, or id.Name (which is the AzureName), but we aren't.

I suspect we have a similar but for the other Authorization rules, and we didn't notice because our tests for those have AzureName == rule.Name so it works fine.

I'll send a PR.

[matthchr]

A fix for this is now merged. It will be included in the v2.12 release, but you can test it out now by updating to run the experimental release of ASO, which contains the fix.