azure-cosmos-dotnet-v3: ApplicationRegion parameter does not work with output from ARM

Describe the bug I have a compute resource in Azure, lets say an AKS cluster. Doesn’t really matter which one since the problem is the same across multiple services:

In my deployment pipeline I run a CLI command to retrieve the region, for instance: az aks show --resource-group my-rg -n mycluster --query "location" --output tsv

This outputs something like northeurope or eastus2. This seems consistent across many Azure resources.

Now, I want to use that output to feed into an app setting which I then want to use to configure my Cosmos DB client with ApplicationRegion:

CosmosClientBuilder clientBuilder = new CosmosClientBuilder(SysConfig.CosmosEndpointUri, SysConfig.CosmosPrimaryKey);
var builderOptions = clientBuilder.WithApplicationRegion(Environment.GetEnvironmentVariable("AZURE_REGION"));

Turns out, you can’t. Because the SDK wants North Europe or East US 2. I don’t see any way how to programmatically split this up

To Reproduce See above.

Expected behavior The SDK should accept standard naming input for Azure regions like northeurope.

Actual behavior See above.

Environment summary SDK Version: 3.14.0

About this issue

Original URL
State: closed
Created 3 years ago
Reactions: 1
Comments: 21 (19 by maintainers)

Commits related to this issue

Allow ComosClientOptions to take ApplicationRegion and ApplicationPreferredRegions in multiple region name formats. This is a proposed fix for - https://github.com/Azure/azure-cosmos-dotnet-v3/issues... — committed to pradeep-chellappan/azure-cosmos-dotnet-v3 by deleted user a year ago
Allow ComosClientOptions to take ApplicationRegion and ApplicationPreferredRegions in multiple region name formats. This is a proposed fix for - https://github.com/Azure/azure-cosmos-dotnet-v3/issues... — committed to iainx/azure-cosmos-dotnet-v3 by deleted user a year ago
CosmosClientOptions: Adds support for multiple formats of Azure region names (#4016) * Allow ComosClientOptions to take ApplicationRegion and ApplicationPreferredRegions in multiple region name forma... — committed to Azure/azure-cosmos-dotnet-v3 by iainx 9 months ago

Most upvoted comments

Should we expect this to be fixed? It is going to be two-year anniversary of this request soon. Does it really take that long to hard code a table or use equality comparer on the existing one that will do .ToLowerInvariant().Replace(" ", "")?

nahk-ivanov on Feb 7, 2023

@ealsur your example is a "regionType": "Logical", I think you can disregard those. Looking at the output I would say only "regionType": "Physical" is important as those are actual regions.

Physical ones seeem to follow the logic, lowercase, no spaces, not special chars

{
    "displayName": "East US 2 EUAP",
    "id": "/subscriptions/0fc3b137-40f9-4c78-a1ae-02bf8065bcd7/locations/eastus2euap",
    "metadata": {
      "geographyGroup": "US",
      "latitude": "36.6681",
      "longitude": "-78.3889",
      "pairedRegion": [
        {
          "id": "/subscriptions/0fc3b137-40f9-4c78-a1ae-02bf8065bcd7/locations/centraluseuap",
          "name": "centraluseuap",
          "subscriptionId": null
        }
      ],
      "physicalLocation": null,
      "regionCategory": "Other",
      "regionType": "Physical"
    },
    "name": "eastus2euap",
    "regionalDisplayName": "(US) East US 2 EUAP",
    "subscriptionId": null
  }

sebader on Mar 25, 2021

Nope, assuming all regions can be normalized the same way.

When listing the Azure regions in the public cloud, there are cases where a “remove spaces, lowercase” does not apply, for example:

{
    "displayName": "United Kingdom",
    "id": "/subscriptions/81cb9df9-8726-4ad7-a878-8385e15c6c4e/locations/uk",
    "metadata": {
      "geographyGroup": null,
      "latitude": null,
      "longitude": null,
      "pairedRegion": null,
      "physicalLocation": null,
      "regionCategory": "Other",
      "regionType": "Logical"
    },
    "name": "uk",
    "regionalDisplayName": "United Kingdom",
    "subscriptionId": null
  },

We can see the Display Name here is United Kingdom but the Name is uk. Which is different than, for example:

{
    "displayName": "United States",
    "id": "/subscriptions/81cb9df9-8726-4ad7-a878-8385e15c6c4e/locations/unitedstates",
    "metadata": {
      "geographyGroup": null,
      "latitude": null,
      "longitude": null,
      "pairedRegion": null,
      "physicalLocation": null,
      "regionCategory": "Other",
      "regionType": "Logical"
    },
    "name": "unitedstates",
    "regionalDisplayName": "United States",
    "subscriptionId": null
  },

Where Display Name is United States and name is unitedstates.

I don’t see how we could apply the same algorithm.

ealsur on Mar 24, 2021

so I guess the feature should actually be “support name or displayName while lowercasing everything” 😄

sebader on Mar 24, 2021

@sebader the beautiful land of Resource Provider independent implementations

ealsur on Mar 24, 2021

Well, I have worked around it by now using a different way, but for future reference, you can make it like this from AKS…

az account list-locations --query "[?name == '$(az aks show -g my-rg -n my-aks --query "location" -o tsv)'].displayName" -o tsv

sample ==> East US

Do I really like that? TBH, no. That’s why I would like to have it as a feature inside the SDK to ideally take either as input: name or displayName

sebader on Mar 24, 2021