1
votes

We have some Azure Table storage tables in our subscription and would like to migrate them to CosmosDB table API due to performance reasons. To do this, I started creating cosmos db account by selecting Table API but my deployment failed with the following error. When i tried with SQL API, it works.

{"code":"DeploymentFailed","message":"At least one resource deployment operation failed. Please list deployment operations for details. "details":[{"code":"BadRequest","message":"{\r\n \"code\": \"BadRequest\",\r\n \"message\": \"CORS rules are not supported for this API\rMicrosoft.Azure.Documents.Common/2.1.0.0\"\r\n}"}]}

Can someone please let me know what could be the reason for this?

2

2 Answers

2
votes

@AngiSen, may be related to a recent (breaking) update of Azure Cosmos DB resource provider (Microsoft.DocumentDb/databaseAccounts) as I just noticed today (28th of Nov 2018) that a previously running deployment (as of 23th of Nov 2018) of Cosmos DB Table API is now failing with this same error:

9:16:23 AM - Resource Microsoft.DocumentDb/databaseAccounts 'xxx-xxx-xxx' failed with message '{ "code": "BadRequest", "message": "CORS rules are not supported for this API\r\nActivityId: xxx, Microsoft.Azure.Documents.Common/2.1.0.0" }'

In my case I'm using 2015-04-08 version with Table API but I don't configure explicitly the CORS part and anyway there's no such configuration option in the resource provider.

Digging into the existing Cosmos DB instance with https://resources.azure.com shows there's indeed a CORS member that is part of the definition:

{ "id": "/subscriptions/xxx/resourceGroups/xxx/providers/Microsoft.DocumentDB/databaseAccounts/xxx", "name": "xxx", "location": "North Europe", "type": "Microsoft.DocumentDB/databaseAccounts", "kind": "GlobalDocumentDB", "tags": {}, "properties": { "provisioningState": "Succeeded", "documentEndpoint": "https://xxx.documents.azure.com:443/", "tableEndpoint": "https://xxx.table.cosmosdb.azure.com:443/", "ipRangeFilter": "", "enableAutomaticFailover": false, "enableMultipleWriteLocations": false, "isVirtualNetworkFilterEnabled": false, "virtualNetworkRules": [], "EnabledApiTypes": "Table, Sql", "databaseAccountOfferType": "Standard", "consistencyPolicy": { "defaultConsistencyLevel": "BoundedStaleness", "maxIntervalInSeconds": 86400, "maxStalenessPrefix": 1000000 }, "configurationOverrides": {}, "writeLocations": [ { "id": "xxx-northeurope", "locationName": "North Europe", "documentEndpoint": "https://xxx-northeurope.documents.azure.com:443/", "provisioningState": "Succeeded", "failoverPriority": 0 } ], "readLocations": [ { "id": "xxx-northeurope", "locationName": "North Europe", "documentEndpoint": "https://xxx-northeurope.documents.azure.com:443/", "provisioningState": "Succeeded", "failoverPriority": 0 } ], "locations": [ { "id": "xxx-northeurope", "locationName": "North Europe", "documentEndpoint": "https://xxx-northeurope.documents.azure.com:443/", "provisioningState": "Succeeded", "failoverPriority": 0 } ], "failoverPolicies": [ { "id": "xxx-northeurope", "locationName": "North Europe", "failoverPriority": 0 } ], "cors": [], "capabilities": [ { "name": "EnableTable" } ] } }

Hope it'll get fixed quickly if it's indeed a breaking change...

1
votes

Wanted to make an official statement here. I have spoken with the Cosmos DB team and they have a fix ready and it should be deployed tonight. Please let me know if you should have any questions. Thank you for posting the issue.