r/kubernetes_cluster: addon_profile.oms_agent.log_analytics_workspace_id should validate the casing

[pedrohdz]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform (and AzureRM Provider) Version

Terraform v0.12.29

• provider.azuread v1.3.0
• provider.azurerm v2.46.1
• provider.helm v2.0.2
• provider.kubernetes v1.13.3
• provider.null v3.0.0
• provider.random v3.0.1
• provider.time v0.6.0

Your version of Terraform is out of date! The latest version
is 0.14.6. You can update by downloading from https://www.terraform.io/downloads.html

Affected Resource(s)

• azurerm_kubernetes_cluster

Actual Behaviour

Same exact issue as in #9151. Looks like this might have not been fixed, or regressed?

The following update on property addon_profile.oms_agent.log_analytics_workspace_id for a azurerm_kubernetes_cluster resource is unneccessary because only the casing is different:

~ log_analytics_workspace_id = "/subscriptions/b55149b2-2597-4455-b224-5159c38e1a2f/resourceGroups/abc-shared/providers/Microsoft.OperationalInsights/workspaces/abc-workspace-f17310012a04c444" -> "/subscriptions/b55149b2-2597-4455-b224-5159c38e1a2f/resourcegroups/abc-shared/providers/microsoft.operationalinsights/workspaces/abc-workspace-f17310012a04c444"

@anhlqn mentioned that they are experiencing the same issue in #9151 (comment).

References

• azurerm_kubernetes_cluster incorrect diff due to casing on addon_profile.oms_agent.log_analytics_workspace_id #9151

[pedrohdz]

@favoretti, pinging you since you worked on the original solution.

[favoretti]

@pedrohdz interesting.. My patch is still there. We might need a state migration here. It's not a new resource I assume?
And out of curiosity, how are you assigning value to that property HCL-wise? Cause strangely enough I don't see the same behavior on any of my clusters (whether new or old)..

[pedrohdz]

@favoretti,
Happening on both new and old clusters. We are assigning it as a constant string, the string is in all lower case.

[favoretti]

Ah, that's why. Proper casing for the resource is the way terraform sets it. Ideally you'd want to fetch that ID back from the resource that created it as azurerm_log_analytics_workspace.name.id, rather than hardcoding a string. You'll have to correct your TF code.

[favoretti]

Azure API resource ID casing isn't super stable, changes from resource to resource, etc, so TF currently constructs consistent casing pretty much in all of the resources regardless of what API gives back. If you still want to use static strings - look into the resource package source code in resourceids.go file - casing there is the one terraform will use.

[tombuildsstuff]

As mentioned above you'll need to update the casing passed in here - but we should also update the validation used on this field to ensure the casing for this field

[pedrohdz]

@favoretti
I think I got it... Just to be a little more exact.. We created the LAWS using terraform months ago. Took the output and hard coded it into a constants variable file that we read from.

If I'm reading you correctly, the output from azurerm_log_analytics_workspace has been updated to output the mixed case. Is that correct?

[tombuildsstuff]

@pedrohdz correct, if you reference using the Data Source or Resource directly, Terraform will update the casing in the background - as such we generally recommend using a Data Source (or Resource) reference to pass the ID's along. Going forwards Terraform will be fixing the casing on some of these older resources to workaround some subtle issues within the Azure API, but this is a gradual effort rather than a big-bang - but we're trying to add validation as we pass through doing this

[pedrohdz]

@tombuildsstuff and @favoretti,
Thank you both so much for the quick turn around and taking the time to explain!

Are these best practices for the AzureRM provider documented anywhere? I looked around and could not find anything.

[tombuildsstuff]

@pedrohdz they're captured in Terraform's documentation - as a general rule we recommend using Resource/Data Source references since it allows us to correctly identify the position of things in the Graph (e.g. if we have a Resource Group, a Network and a Subnet - we can track we should delete the Subnet before the Network before the Resource Group) - but it also gives the side-effect of ensuring the casing is consistent.

Unfortunately the Azure API's are slightly misleading, whilst there's some guidance on Resource ID's, in practice each API implements Resource ID parsing sufficiently differently (some case-sensitively, some case-insensitively, some returning the incorrect casing, some returning it as it was submitted..) that we're forced to treat these as case sensitive (and as mentioned above we're trying our best to fix these as time goes on). As such whilst this guidance can apply to the other Providers - it's most applicable to Azure due to the ID's being URI's rather than (say) a UUID (or similar) in other providers.

[ghost]

This has been released in version 2.47.0 of the provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. As an example:

provider "azurerm" {
    version = "~> 2.47.0"
}
# ... other configuration ...

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!