Compute: AvailabilitySetsClient, VirtualMachinesClient, VirtualMachineScaleSetsClient return incorrect casing for the Proximity placement group ID (resource group name is lower cased)

[katbyte]

Bug Report

• import path of package in question, e.g. .../services/compute/mgmt/2018-06-01/compute
"github.com/Azure/azure-sdk-for-go/services/compute/mgmt/2018-06-01/compute"
• SDK version e.g. master, latest, 18.1.0
github.com/Azure/azure-sdk-for-go v32.5.0+incompatible
• output of go version

go version go1.12.6 darwin/amd64

• What happened?
  The clients AvailabilitySetsClient, VirtualMachinesClient, VirtualMachineScaleSetsClient return incorrect casing for the Proximity placement group ID (resource group name is lower cased)

• What did you expect or want to happen?
  The PPG id returned with the correct casing.

• How can we reproduce it?
  Create one of the affected resources with a PPG in a resource group with capitals & check the casing returned

• Anything we should know about your environment.

[ArcturusZhang]

Hi @katbyte could you please provide some more detailed information? Such as the parameters you are using and the response the service returns, etc.

[katbyte]

It happens no matter what parameter we send, the service always returns it in lower case. see discussion here: hashicorp/terraform-provider-azurerm#4020

[ghost]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @mjconnection, @Drewm3

[Drewm3]

Is the problem in the casing of the resource group name or the PPG? The resource group name casing is not guaranteed in the responses from the Microsoft.Compute resource provider.

[katbyte]

@Drewm3, the problem is the casing of the resource group name does not match the actual case of the resource group name. This behaviour does not match the majority of azure APIs.

[Drewm3]

Thanks for the feedback. I do understand it is a bit challenging when the casing is inconsistent, but this is "by design" currently for VMs and associated resources. The development team does have a replacement design that will support retaining case in the future, but this is unfortunately a very large work item due to the current backend implementation. So I do not know when we will be able to update the platform to support the retaining of the case based on what is first seen by the compute resource provider.

[ghost]

Thanks for working with Microsoft on GitHub! Tell us how you feel about your experience using the reactions on this comment.

[katbyte]

@Drewm3, @jhendrixMSFT,

I'm not sure why this issue was closed? I don't see any resolution other then an explanation for why a fix will take a while. Could we please keep this issue open for tracking until it is actually fixed as it is linked to in code & PRs?

[Drewm3]

This is closed because it is by design. Please feel free to open design changes or feature requests here: https://feedback.azure.com/forums/216843-virtual-machines.

Unfortunately, it is exceptionally difficult to manually manage feature requests for the entire surface of the VM product in GitHub.

[ghost]

Thanks for working with Microsoft on GitHub! Tell us how you feel about your experience using the reactions on this comment.

[katbyte]

@Drewm3,

I'm not sure what by "design" implies but as a consumer of this API & SDK this is very much a bug. The service is changing the resource group name in a way inconsistent with the rest of Azure so i'm not sure why this is a feature request?

[Drewm3]

I cannot speak for the behavior of other resources. However, for VMs the behavior is the expected behavior from the backend system. Changing the expected behavior is going to be a design change which we typically call a feature. I cannot say that I 100% agree that the current expectation is the best. I am only sharing that the current behavior is what is expected.