Azure-sdk-for-go: Container Registry API returns Storage Account ID in lower-case

[tombuildsstuff]

👋

Our automated tests have detected a change in the Container Registry API where the Storage Account ID field is now being returned in lower-case rather than matching the casing/format used by the Storage Accounts API (as is the convention in the rest of Azure). Specifically, when sending the value:

/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/testAccRg-2825161317986571725/providers/Microsoft.Storage/storageAccounts/testaccsaxbvj

(which is the ID returned from the Storage Accounts Service) we get back the value:

/subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/testaccrg-2825161317986571725/providers/microsoft.storage/storageaccounts/testaccsaxbvj

This is using API version 2017-10-01 in SDK v16.2.1 - and we first noticed this change on the 25th May 2018 (we're trying this in West Europe, but I assume it's a global change) if that helps correlate it in any way.

Would it be possible to fix the broken API? This is causing spurious diff's at our end

Thanks!

[joshgav]

@stevelasker can you address this? Thanks!

[sajayantony]

Not sure why this would have regressed. @ehotinger took a look quickly and will follow up.
But I wasn't unable to repro this either -
https://github.com/sajayantony/acr-mgmt-test/blob/master/main.go

[SteveLasker]

We should also add that we are working towards deprecating Classic, which is the only tier that supports a storage account.
If this is for completeness, understood and we’ll see how/if this is a regression.
From an investment perspective, we haven’t done any recent work in classic and ask customers to use basic, standard or premium. Aka.ms/ACR/skus

[ehotinger]

@tombuildsstuff can you provide a minimal self-contained repro for this? Just a gist or whatever to show how you're utilizing the SDK. And/or source code for your tests. Feel free to @ me and I'll look at it further.

[tombuildsstuff]

@ehotinger sure, here's the code we use to create the Container Registry, the code used to Get the Container Registry and the Acceptance Test in question which uses this Terraform Configuration which spins up a Resource Group, Storage Account and then a Classic Container Registry via Terraform - and then (implicitly) asserts that the casing of the Storage Account ID matches the casing used for the ID of the Storage Account.

I can put together a small repro if it helps, but it should be possible to use this Terraform Configuration:

resource "azurerm_resource_group" "test" {
  name     = "azuresdkgo-bug1943"
  location = "West Europe"
}
resource "azurerm_storage_account" "test" {
  name                     = "tfteststorabc12653"
  resource_group_name      = "${azurerm_resource_group.test.name}"
  location                 = "${azurerm_resource_group.test.location}"
  account_tier             = "Standard"
  account_replication_type = "LRS"
}
resource "azurerm_container_registry" "test" {
  name                = "tftestcr12653"
  resource_group_name = "${azurerm_resource_group.test.name}"
  location            = "${azurerm_resource_group.test.location}"
  admin_enabled       = false
  sku                 = "Classic"
  storage_account_id = "${azurerm_storage_account.test.id}"
  tags {
    environment = "production"
  }
}

and then run terraform init then terraform apply; once that's completed you can then run terraform plan which will show the difference in casing.

Hope that helps :)

[ehotinger]

@tombuildsstuff a minimal repro would be extremely helpful if you don't mind. Can you also cross-reference @sajayantony's example he shared above with your own sub id? His example's more or less identical to the client.Get call you have, which I can't repro bad casing for.

[tombuildsstuff]

@ehotinger I've added an example in this repro: https://github.com/tombuildsstuff/azure-sdk-for-go-bug-1943

e.g.

$ go build . && envchain azurerm ./azure-sdk-for-go-bug-1943

2018/06/21 19:01:06 Creating Resource Group..
2018/06/21 19:01:11 Creating Storage Account..
2018/06/21 19:01:31 Retrieving Storage Account..
2018/06/21 19:01:32 Storage Account ID (from Storage Account): "/subscriptions/c0a607b2-6372-4ef3-abdb-dbe52a7b56ba/resourceGroups/bug1943-resources/providers/Microsoft.Storage/storageAccounts/bug1943stor"
2018/06/21 19:01:32 Creating Classic Container Registry..
2018/06/21 19:01:38 Retrieving Storage Account ID from Classic Container Registry..
2018/06/21 19:01:38 Storage Account ID (from Registry): "/subscriptions/c0a607b2-6372-4ef3-abdb-dbe52a7b56ba/resourcegroups/bug1943-resources/providers/microsoft.storage/storageaccounts/bug1943stor"
2018/06/21 19:01:38 Deleting Resource Group..
2018/06/21 19:01:40 Waiting for deletion of Resource Group to complete..
2018/06/21 19:03:13 Deleting Storage Account..
2018/06/21 19:03:15 Deleting Classic Container Registry..

Hope that helps :)

[ehotinger]

Thanks @tombuildsstuff, we're looking at it.

[ehotinger]

Btw @tombuildsstuff - small update. This fix should be deployed in South Central US, global deployment 7/23. Give it a try around 7/24 and post an update.

[tombuildsstuff]

@ehotinger so I've just run our test suite against South Central US and I can confirm this release fixes this issue - thanks for confirming, looking forward to this rolling out globally :)

[tombuildsstuff]

just to give an update here - I can confirm this is now fixed in West Europe (where our tests run) - as such I'm going to close this issue. Thanks again for getting this fixed :)