Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support multiple formats of Azure region names for CosmosClientOptions #3857

Conversation

pradeep-chellappan
Copy link
Contributor

Description

This is a proposed fix for - #2330
We want to set CosmosClientOptions.ApplicationRegion and CosmosClientOptions.ApplicationPreferredRegions in the format that ARM exposes it. For e.g. if the region is West US 2, the CosmosClientOptions should accept both "West US 2" and "WestUs2" and "westus2". This gives maximum flexibility to the users of the SDK.
To enable this, I keep a mapping between the normalized region name and the one that CosmosDB SDK uses internally. When CosmosClientOptions.ApplicationRegion or CosmosClientOptions.ApplicationPreferredRegions is set, the region names are converted, if required.

Type of change

Please delete options that are not relevant.

  • [] New feature (non-breaking change which adds functionality)

Closing issues

To automatically close an issue: closes #2330

…ferredRegions in multiple region name formats.

This is a proposed fix for - Azure#2330
@pradeep-chellappan
Copy link
Contributor Author

@microsoft-github-policy-service agree company="DocuSign"

Copy link
Member

@kirankumarkolli kirankumarkolli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please check comments


foreach (FieldInfo field in fields)
{
normalizedToCosmosDBRegionNameMapping[field.Name.ToLowerInvariant()] = field.GetValue(null).ToString();
Copy link
Contributor

@sourabh1007 sourabh1007 May 22, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how did we make sure that it is applicable for all the regions? Is other SDKs are following this logic? or it is just observation and relying on adding condition if we found/add any new region which is not following this pattern (even in future)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is applicable to all regions where CosmosDB currently runs (based on the Regions class).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sourabh1007 its possible that some other azure RP's returning/expecting in different form.
One example that was mentioned with "-" by @FabianMeiswinkel

We will learn more as we uncover and fill the gaps forward

/// </summary>
internal class RegionNameMapping
{
private static readonly IDictionary<string, string> normalizedToCosmosDBRegionNameMapping;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Usage is one at the client initialization level. Caching is unnecessary.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, but what is the caching that you are referring to?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kirankumarkolli - I did not understand your comment. Could you please clarify?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Static dict<> lifetime is process lifetime. Where as the usage of the dict<> is just one method call at the ClientInitialization time only.

So static instance/cache is unnecessary, it can be created once as local state.

@kirankumarkolli
Copy link
Member

@pradeep-chellappan can you please take a look at comments?

@kirankumarkolli
Copy link
Member

@pradeep-chellappan Can you please look into the comments.

We want to ship this feature ASAP. We will wait for your update till 07/14 and after that we will move forward with a new PR replicating the changes.

@pradeep-chellappan
Copy link
Contributor Author

@pradeep-chellappan Can you please look into the comments.

We want to ship this feature ASAP. We will wait for your update till 07/14 and after that we will move forward with a new PR replicating the changes.

Hey Kiran, could you please reply to my prior comment regarding the caching?


static RegionNameMapping()
{
FieldInfo[] fields = typeof(Regions).GetFields(BindingFlags.Public | BindingFlags.Static);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ealsur how about include all (non-public) also?

Its more about future proofing where the region might be added as internal before going public. And string/text based API's will still be functional right?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't have cases where "Regions" contains internal names. We have cases where "LocationNames" (which is internal itself) contains regions that are not ready though. When they are not ready, there is no mapping in RegionProximityUtil either.
So adding also Internals here would not enable any scenario.

public string ApplicationRegion
{
get => this.applicationRegion;
set => this.applicationRegion = RegionNameMapping.GetCosmosDBRegionName(value);
Copy link
Member

@kirankumarkolli kirankumarkolli Jul 12, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Application input is updated right on setter. Functionally works.
One other alternative is to keep original values as Application configured and then later during CosmosClient initialization do conversation.

@ealsur, @FabianMeiswinkel any preferences?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer also having the original UserAgent input in the diagnostics - so, both the normalized and original values. Keeping the original value in ApplicationRegion and then client on initialization normalizing it is porbably the easiest way to get above.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No preference. On the Diagnostics we log the value of the public getter:

this.ConsistencyConfig = new ConsistencyConfig(cosmosClientContext.ClientOptions.ConsistencyLevel,
cosmosClientContext.ClientOptions.ApplicationPreferredRegions, cosmosClientContext.ClientOptions.ApplicationRegion);

The only thing with this approach is that the getter does not return the same value that was set, so if anyone is validating that if I set West US, I get West US, the test will fail.

Making the conversion internally on:

if (this.ApplicationRegion != null)
{
connectionPolicy.SetCurrentLocation(this.ApplicationRegion);
}
if (this.ApplicationPreferredRegions != null)
{
connectionPolicy.SetPreferredLocations(this.ApplicationPreferredRegions);
}

Would achieve the same thing while keeping the getter value matching the user input.


foreach (FieldInfo field in fields)
{
normalizedToCosmosDBRegionNameMapping[field.Name.ToLowerInvariant()] = field.GetValue(null).ToString();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Coverage for spaces" Ref: #2330 (comment)

I.e. if the incoming name doesn't have spaces also it should match.

@kirankumarkolli
Copy link
Member

@pradeep-chellappan Can you please look into the comments.
We want to ship this feature ASAP. We will wait for your update till 07/14 and after that we will move forward with a new PR replicating the changes.

Hey Kiran, could you please reply to my prior comment regarding the caching?

Thanks you @pradeep-chellappan, please check updated comments.

@ealsur
Copy link
Member

ealsur commented Oct 11, 2023

Closed through #4016

@ealsur ealsur closed this Oct 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

ApplicationRegion parameter does not work with output from ARM
7 participants