A first create AKS with omsagent set to enabled, the omsagent config key is case sensitive:
Create AKS with omsagent enabled
REQUEST
{
...
"properties": {
"addonProfiles": {
"omsagent": {
"config": {
"logAnalyticsWorkspaceResourceID": "/subscriptions/0-0-0-0/resourcegroups/example222/providers/microsoft.operationalinsights/workspaces/example222"
},
"enabled": true
}
}
},
...
}
RESPONSE
(same as REQUEST)
Then if I disable the omsagent then enable it, the case of the omsagent.config is lost (i.e. logAnalyticsWorkspaceResourceID):
Enable omsagent after firstly disabling it
REQUEST
{
...
"properties": {
"addonProfiles": {
"omsagent": {
"config": {
"logAnalyticsWorkspaceResourceID": "/subscriptions/0-0-0-0/resourcegroups/example222/providers/microsoft.operationalinsights/workspaces/example222"
},
"enabled": true
}
}
},
...
}
RESPONSE
{
...
"properties": {
"addonProfiles": {
"omsagent": {
"config": {
"loganalyticsworkspaceresourceid": "/subscriptions/0-0-0-0/resourcegroups/example222/providers/microsoft.operationalinsights/workspaces/example222"
},
"enabled": true
}
}
},
...
}
The expected behavior is to always respect the case.
Related issue: terraform-providers/terraform-provider-azurerm#8344
Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @Azure/aks-pm.
One fix for this would be to model this as a struct in the swagger, rather than a dictionary? Whilst being a dictionary can be convenient (in that new fields can be added without modifying the swagger) it allows breaking changes to slip through unnoticed - so this may be better long-term, since this is the second/third time this has happened that I can recall?
Edit: the same issue happens on httpApplicationRouting config key httpapplicationroutingzonename.
See: terraform-providers/terraform-provider-azurerm#8326
@robbiezhang @vishiy @saaror
Hi all, this is Robbie from the AKS team. Sorry about the breaking change. We're working on a hotfix to revert it back to the previous behavior - preserve the casing from the user input. Please kindly stay tuned.
@robbiezhang thanks for the hotfix - is it worth making this a nested block in the Swagger, rather than a Dictionary to avoid this bug going forwards?
Tom, thanks for the suggestion. We had an internal discussion about whether to schematize the addonProfiles. The major concern is about the compatibility of the existing clients. We have optimization on the server side to make the addon name and config name case insensitive based on customers' feedback. Schematized the addonProfiles will break the clients. IMO, addonProfiles is a playground to onboard an addon quickly. When the addon goes to stable, it should be extracted and moved into a new property, which is schematized, and couple the new property with a new api-version. What do you think?
I only just started seeing this. Is this a regression? I don't have to disable anything, but every time I run apply, it wants to correct the case of the log_analytics_workspace_id.
Most helpful comment
Hi all, this is Robbie from the AKS team. Sorry about the breaking change. We're working on a hotfix to revert it back to the previous behavior - preserve the casing from the user input. Please kindly stay tuned.