Open matthchr opened 2 years ago
ARM
Thank you for your feedback. This has been routed to the support team for assistance.
The request that doesn't filter correctly has the resource types cased differently than the one that works: Routing request from WestUS cases it like this: Microsoft.ContainerService/managedClusters Routing request from WestCentralUS cases it like this: microsoft.containerservice/managedclusters
The --query
parameter is case sensitive which is by designed, because it uses the jmespath syntax.
So this issue requires the REST service to solve the problem of inconsistent case
FYI as per #24542, the new JMESPath Community build of the Python library supports the lower()
function that would help support case insensitive comparison.
I am also encountering this issue and would really love to hear when this can be resolved or what are other ways to achieve a consistent result.
Got a workaround for my CRON Job by supplying all possible casing of the VMName that I am using as parameter in my query. Not pretty but it works until that lower function gets included in Azure CLI.
When should we expect that lower function from JMESPath be included in Azure CLI?
To be transparent, that does not seem highly likely at all.
Related command az resource list --tag freeforpipeline=true --query "[?type=='Microsoft.ContainerService/managedClusters']" --debug
Describe the bug
az resource list
with--query
parameter returns inconsistent results across multiple runs. I have used the--debug
flag and can clearly see that the service is returning the correct data in the GET request payload, but that data is not being consistently returned in the result of theaz resource list
call. Sometimes it works, sometimes it doesn't work. In my case my list should always return 5 items, but sometimes it's returning 5 and sometimes it's returning 0. Repeated runs can quickly fluctuate between 5 and 0 results. There are no changes on the actual resources in question, they should always match the query.To Reproduce Create a few resources with a tag (my tag was
freeforpipeline=true
) and try to query them withaz resource list --query
.Expected behavior My collection of 5 resources should be returned every time, because all 5 of them match
Environment summary I have reproduced this problem in 2 environments:
Linux Install method: apt Shell: Bash
Windows Install method: MSI Shell: cmd.exe
Additional context
Logs from a successful call:
The key difference seem to be that the successful request has
'x-ms-routing-request-id': 'WESTUS:20220714T205234Z:cfe7657b-51b1-4e4d-b3c3-61cb696fece2'
, while the request that doesn't filter correctly has'x-ms-routing-request-id': 'WESTCENTRALUS:20220714T205344Z:f72a16df-5452-456d-88f9-fa1d7c86c89b'
The request that doesn't filter correctly has the resource types cased differently than the one that works: Routing request from WestUS cases it like this:
Microsoft.ContainerService/managedClusters
Routing request from WestCentralUS cases it like this:microsoft.containerservice/managedclusters