Open taurit opened 3 years ago
network
@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.
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 |
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-access
And 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.
network service team should look into this
Any progress here? We are experiencing the same problem. Empty list towards some resource groups and non-empty lists towards other resource groups
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?
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
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.
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
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
nodeResourceGroup
to some unique value, eg.resourcegroup-123
. 2) Shortly after the cluster is deployed, runaz network vnet list -g resourcegroup-123
3) The response often is empty array[]
, even if virtual network already exists and is accessible from other instances ofaz cli
or 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 cli
we're using to issue query.Environment summary
Additional context I ran
az network vnet list -g {rgName} --debug
(with the--debug
parameter). 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 --debug
is 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