yonzhan
commented
3 years ago network
Open taurit opened 3 years ago
yonzhan
commented
3 years ago network
msyyc
commented
3 years ago @service team. According to the debug info, the client send same request body with same rest api, but the response is different. Please pay attention to it.
ghost
commented
3 years ago Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @aznetsuppgithub.
| Author: | taurit |
|---|---|
| Assignees: | msyyc |
| Labels: | `Network`, `Service Attention` |
| Milestone: | S184 |
hollowdrutt
commented
2 years ago Any progress on this? I ran into the problem while trying to follow along the book Hands-On Kubernetes on Azure where you are instructed to run the commands:
nodeResourceGroup=$(az aks show -n handsonaks \
-g rg-handsonaks -o tsv --query "nodeResourceGroup")
aksVnetName=$(az network vnet list \
-g $nodeResourceGroup -o tsv --query "[0].name")
aksVnetId=$(az network vnet show -n $aksVnetName \
-g $nodeResourceGroup -o tsv --query "id")
az network vnet peering create \
-n AppGWtoAKSVnetPeering -g agic \
--vnet-name agic-vnet --remote-vnet $aksVnetId \
--allow-vnet-accessAnd it becomes quite confusing when it doesn't work and the vnet is visible in the Azure Portal but az network vnet list returns [].
After 10 minutes or so the command started to return the correct result.
yonzhan
commented
2 years ago network service team should look into this
borgewi
commented
2 years ago Any progress here? We are experiencing the same problem. Empty list towards some resource groups and non-empty lists towards other resource groups
ivan-nushev
commented
1 year ago It was observed similar behaviour in a subscription of the company I am working for. In a time interval of 10 minutes we poll Azure VirtualNetworks API through Azure Java library version 1.41.3. Regular results of that poll contain all 25 VirtualNetworks but in an occasional result there were only 7. After the odd result the client continued to return all 25 VirtualNetworks. This behaviour is observed in rare cases but its impact is significant as our application logic performs some cleanup of VirtualNetworks application specific representations when there is discrepancy. Why does Azure library misbehave? What can we do to mitigate it? Is there a fix for this in newer library versions?
pawel-zolty
commented
1 year ago I have similar problem. I have done this exercise from az-700. I used az cli instead of azure portal to create resources. When I list vnets with az network vnet list --query "[[].name]" I can see:
[
[
"ManufacturingVnet",
"ResearchVnet"
]
]There is not CoreServicesVnet. In Azure Portal I can see three vnets. I am sure that 3 vnets exists
fals
commented
1 year ago I have the same issue when using the Azure SDK for Go, when creating a new cluster all resources are available on azure portal, the cluster works as intended, but if you try to list the vnets you get nothing from that cluster. Sometimes it takes Hours to have the correct result from the API.
shirsa
commented
1 year ago I have the same issue with: az network private-endpoint list
When the request is routed through QATARCENTRAL the response is empty.
When the request is routed through FRANCESOUTH the response is as expected and the response also contains x-ms-arm-service-request-id header
v-maxjohnson
commented
2 months ago Are you working on this @necusjz? This issue still occurs, and it has been open multiple years now.
Describe the bug The command
az network vnet list -g {rgName}sometimes repeatedly returns incorrect value (empty array,[]). The same command executed on another machine at the same time for the same resource (e.g. from Cloud Shell in Azure Portal) returns correct, non-empty result.To Reproduce This might be complex to reproduce in practice. I think that the correlation ids from logs might be more useful. But the scenario is: 1) Deploy AKS cluster using ARM template. Set the parameter
nodeResourceGroupto some unique value, eg.resourcegroup-123. 2) Shortly after the cluster is deployed, runaz network vnet list -g resourcegroup-1233) The response often is empty array[], even if virtual network already exists and is accessible from other instances ofaz clior Azure Portal. 4) Retry several times. The response can often be[]for 40 minutes of retries or longer. Then it can start responding properly, or our pipeline times out.Expected behavior The command should return the same list of virtual networks in the resource group, regardless of the instance of
az cliwe're using to issue query.Environment summary
Additional context I ran
az network vnet list -g {rgName} --debug(with the--debugparameter). Here is the interesting part that shows the response is insonsistent across clients:Output from Azure Pipelines:
Output from Cloud Shell in Azure Portal:
Full output of
az cli --debugis attached: 2021-03-12_08-35-24-run-from-azure-pipelines-returns-empty-array.txt 2021-03-12_08-44-06-run-from-azure-portal-cli-returns-correct-result.txt 2021-03-12_08-50-30-run-from-azure-pipelines-returns-empty-array-again.txt