Describe the bug
When creating an OpenAI deployment (Microsoft.CognitiveServices/accounts/deployments@2023-05-01), there's no option to set rateLimits property. But when running what-if with bicep file, the Modify change is found on rateLimits parameter and deployment is changed.
az deployment group create --resource-group myresourcegroup \
--mode Incremental \
--template-file deploy.bicep
Run az group what-if using that file.
az deployment group what-if --resource-group myresourcegroup \
--mode Incremental \
--template-file deploy.bicep
Observe that output shows Delete should happen on rateLimits.
Note: The result may contain false positive predictions (noise).
You can help us improve the accuracy of the result by opening an issue here: https://aka.ms/WhatIfIssues
Resource and property changes are indicated with these symbols:
- Delete
~ Modify
* Ignore
The deployment will update the following scope:
Scope: /subscriptions/XXXXXX/resourceGroups/myresourcegroup
~ Microsoft.CognitiveServices/accounts/mygpt/deployments/myDeployment [2023-05-01]
- properties.rateLimits: [
0:
count: 1
key: "request"
renewalPeriod: 10
1:
count: 1000
key: "token"
renewalPeriod: 60
]
* Microsoft.CognitiveServices/accounts/mygpt
Resource changes: 1 to modify, 1 to ignore.
Expected behaviorrateLimits shouldn't be interpreted as a change as it's not set by the request and shouldn't result in a change in az group create
Describe the bug When creating an OpenAI deployment (Microsoft.CognitiveServices/accounts/deployments@2023-05-01), there's no option to set rateLimits property. But when running what-if with bicep file, the Modify change is found on rateLimits parameter and deployment is changed.
To Reproduce Steps to reproduce the behavior:
Expected behavior rateLimits shouldn't be interpreted as a change as it's not set by the request and shouldn't result in a change in az group create