Azure
[Bug Report]: Log Analytics workspaces etag field not valid
Describe the bug
When deploying a log analytics workspace using the Microsoft.OperationalInsights/workspaces module, the following warning appears:
E:\repos\test\modules\carml\0.5.0\Microsoft.OperationalInsights\workspaces\savedSearches\deploy.bicep(55,5) : Warning BCP037: The property "etag" is not allowed on objects of type "SavedSearchProperties". No other properties are allowed. If this is an inaccuracy in the documentation, please report it to the Bicep Team. [https://aka.ms/bicep-type-issues]
If this can be confirmed to be an error, it should be enough to remove the following lines: https://github.com/Azure/ResourceModules/blob/7eaa7edfc07f7db4fe5e255f07ebc22175777918/arm/Microsoft.OperationalInsights/workspaces/deploy.bicep#L206 https://github.com/Azure/ResourceModules/blob/7eaa7edfc07f7db4fe5e255f07ebc22175777918/arm/Microsoft.OperationalInsights/workspaces/savedSearches/deploy.bicep#L55
To reproduce
Deploy a log analytics workspace using the Microsoft.OperationalInsights/workspaces module.
Code snippet
No response
Relevant log output
No response
Hey @itpropro, I actually brought this up with the PG some time back.
Long story short, it seems to be a provider inaccuracy. The API tells you to place the etag outside the param block, but if you do that, the deployment doesn't work. It does however inside the block.
This was originally introduced by @SeSeicht in this PR: #1413.
I can confirm that moving the etag inside the properties object does allow a deployment, the warning is definitely incorrect. Adding the etag property allows me to redeploy the hunting rule without any errors in Azure.
Couple screenshots if they help.
Thanks for the explanation, where is the issue tracked with the Bicep team @MrMCake ?
Hey @itpropro , I raised the issue in the 'offical' "Missing type validation / inaccuracies" issue here (just expand Microsoft.OperationalInsights/workspaces/savedSearches).
There have also been a couple comments to it underneath.
I'll go ahead and close this issue here as fixing it appears to be outside of CARML's reach and something either the ARM/Bicep PG or the Provider-PG have to fix on their end.