Inconsistent casing in Batch Certificate IDs

[stuartleeks]

When creating a Batch Certificate the ID returned sets the certificate name portion to uppercase, e.g.

/subscriptions/xxx-xxx-xxx/resourceGroups/ztestaccbatch2/providers/Microsoft.Batch/batchAccounts/sltestaccbatch2/certificates/SHA1-42C107874FD0E4A9583292A2F1098E8FE4B2EDDA

But when you reference a certificate in a Batch Pool the name portion is returned in lowercase:

/subscriptions/xxx-xxx-xxx/resourceGroups/ztestaccbatch2/providers/Microsoft.Batch/batchAccounts/sltestaccbatch2/certificates/sha1-42c107874fd0e4a9583292a2f1098e8fe4b2edda

It would be helpful (e.g. for downstream consumers such as the Terraform AzureRm Provider if the IDs were at least consistent within a given service)

[kpajdzik]

@jafreck, @xingwu1, any comments here?

[katbyte]

👋 Hello, any word on this?

@jhendrixMSFT

[xingwu1]

The quote from @kiwidev

And technically, I thought the desired ARM behavior was: “remember the case of the last PUT/PATCH request to the resource”… i.e. the case of an ID can change based on the last request…

Here’s the quote (https://github.com/Azure/azure-resource-manager-rpc/blob/master/v1.0/resource-api-reference.md):

The resource group names and resource names should be matched case insensitively. That means, for example, if a user creates a resource in resource group "rG1", and then calls a read operation on "RG1", the same resource should be returned even though the casing differs.

Additionally, we MUST preserve the casing provided by the user. That means we should return back the most recently specified casing to the client (and we MUST not normalize / return back a toupper/tolower form of the resource group or resource name, for example).

The resource group name and resource name MUST come from the URL and not the request body. That is because there is no writable property for resource group, and the property is optional for PUT / PATCH (but the URL is REQUIRED).

So yes, we can fix it – but it seems like terraform assumptions are flawed…

@kiwidev When do you plan to fix it?

[kiwidev]

We will put out a change to normalize this id in both places to lowercase.

This should be in production within a couple of weeks.

However, note that assuming ARM ids do not change case seems to be a dangerous assumption as the ARM specification states that these ids can change case.

[bgklein]

Confirmed with @kiwidev that this fix has been pushed to production.