Kusto - upgrade API Version from 2022-02-01 to 2022-12-29

[liuwuliuyun]

New API Swagger Link

https://github.com/Azure/azure-rest-api-specs/blob/main/specification/azure-kusto/resource-manager/Microsoft.Kusto/stable/2022-12-29/kusto.json

Content

• RP Kusto - upgrade API Version from 2022-02-01 to 2022-12-29

Special Change for property language_extensions

Context

Currently, we are using an old API version (2022-02-01) where language_extensions is a read-only property and we have a separate API to manage its CRUD operations. We first create a kusto cluster with a PUT request without specifying language_extensions, and then we use the separate API to add or remove them.

However, in the new API version (2022-12-29) that we want to upgrade to, language_extensions is a read-write property and it has a new required sub property called LanguageExtensionImageName. This means that if we use the same PUT request as before, it will delete all existing language_extensions.

On the other hand, if we specify language_extensions in the PUT request, we must provide the LanguageExtensionImageName for each of them, which may not be available or known by the customers.

This change is challenging because it breaks the existing behavior and expectations of the customers who use the azurerm_kusto_cluster resource. But if we don’t do API upgrading. It will block the adoption of a new resource called azurerm_kusto_cosmosdb_data_connection, which only exists in the new api version.

Solution

Team members had a meeting discussing this. Our solution:

For version 3.x we have three different names.

Use language_extensions = 'PYTHON' to represent

{
  "languageExtensionName": "PYTHON",
  "languageExtensionImageName": "Python3_6_5" (defualt value retrevied by GET)
}

Use language_extensions = 'PYTHON_3.10.8' to represent

{
  "languageExtensionName": "PYTHON",
  "languageExtensionImageName": "Python3_10_8"
}

Use language_extensions = 'R' to represent

{
  "languageExtensionName": "R",
  "languageExtensionImageName": "R" (defualt value retrevied by GET)
}

For 4.0 and later version, we use a new block called language_extension which is optional and has two required properties. And works like following:

resource "azurerm_kusto_cluster" "example" {
  ...
  language_extension {
     name  = "PYTHON"
     image = "Python3_10_8"
  }
  ...
}

Testing Evidence

All failed tests also failed on main branch. Will address them seperately.

Welcome any feedback on this PR

[katbyte]

we have a test failure here

Error: creating/updating Cluster (Subscription: "*******"
        Resource Group Name: "acctestRG-230601164428475644"
        Cluster Name: "acctestkcntdjg"): performing CreateOrUpdate: clusters.ClustersClient#CreateOrUpdate: Failure sending request: StatusCode=0 -- Original Error: Code="BadRequest" Message="The sku Standard_D32d_v5 is not supported in westus2"
        

[liuwuliuyun]

we have a test failure here

Error: creating/updating Cluster (Subscription: "*******"
        Resource Group Name: "acctestRG-230601164428475644"
        Cluster Name: "acctestkcntdjg"): performing CreateOrUpdate: clusters.ClustersClient#CreateOrUpdate: Failure sending request: StatusCode=0 -- Original Error: Code="BadRequest" Message="The sku Standard_D32d_v5 is not supported in westus2"
        

This test failed because sku is not supported in the test region. I pick a more common sku and update the test accordingly.

[katbyte]

LGTM ⛈️

[github-actions]

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.