azure-cli: 'az network nsg list' returns an incorrect result

Describe the bug

Hello, I use az aks create ... to create a cluster. After successful creation, I want to receive information about NSG using az network nsg list. But it returns the empty result. I also tried something like az resource list --resource-type Microsoft.Network/networkSecurityGroups- it does not help. But I see via Portal, that NSG is successfully created. I need to wait a while (about 10 min) to get the correct result via az network nsg list. The same behavior is for az network vnet.

Could you please explain, what needs to be triggered for correct behavior? Or just need to call additional wait?

Additional context I found that there is very similar issue #15303, but there is no answer for a long time.

Thank you.

About this issue

  • Original URL
  • State: open
  • Created 3 years ago
  • Comments: 28 (12 by maintainers)

Most upvoted comments

I am hoping this may help others, as well provide some venting for myself…

I have been plagued by this issue for a long time now, I would say years!! It seriously hinders ones ability to reliably automate any sort of deployments through Azure Devops or even on home rolled apps, utilities or services. And probably broadly more tech.

I have experienced this problem with ARM, Powershell: Azure RM and AZ modules, any version. I have experienced this problem making calls directly to rest endpoints. And, now I have experienced it with the AZ cli after switching all code to use it because of the touted reliability. Each time switching to new versions or technology in hopes to get away from this issues. You create a resource and it may or may not show up immediately <shrug>.

It started noticing it trying to dynamically collect resources under a resource group so that I could apply tags post creation of AKS, via arm. Vnet, public-ip, lb or nsg. I have even experienced this with more basic resources like storage. Doesn’t matter what the initiating technology is. I have gone as far as to implement all sorts of rediculous sleeps and retry logic that can cause deployments to take several hours instead of minutes.

I have opened tickets with ARR support and their response (my summation), after much back and forth, was that you can’t rely on these calls. And that I should make calls to the resource graph as it gets updated immediately post resource creation and the older resource management updates much more slowly. And resource updates take time to propagate to other regions. I found this particularly troublesome with devops as there is no guarantee when using hosted agents that you will end up in the same region that you are deploying too, and moving from stage to stage your region “could” change and that region may not have had the updates.

I will say this. Graph explorer has been VERY consistent so far. And immediate. I can confirm it is more reliable, but it doesn’t solve all the needs that you would rely on these other tools or calls for. I have seen delays on created resources anywhere from 5min to over 24 hours!!

an example of graph explorer query that is guaranteed to return resources would be : az graph query -q "Resources | project Name=name, Location=location, ResourceGroupName=resourceGroup, ResourceType=type, Tags=tags, ResourceId=id | where ResourceGroupName =~ '$($resourceGroupName)'

But of course, even if it returns the items correctly, if you need to operate on the resource you are probably trying to leverage other commands that won’t work because the resource isn’t visible, except to graph.

This is a serious problem that really needs MS attention. I can appreciate the immense complexity involved, but this is a fundamental problem for anyone trying to really embrace modern development principals and devops.

Please put some fire on this. I would really like to be able to rely on the resources I think i have created.

I am using West Europe region.

Here is an example script to illustrate the issue: aks-nsg-issue.txt

Once reaching step 5, I’ve also did experiments to request the NSG list using other accounts with access to the subscription, but it does not matter.

Edit: There is a small issue with the script, which I did too quickly. The listing of the NSG groups is querying for the RG of the AKS itself, but the NSG is created under a RG that is automatically created for the nodes and other network resources automatically created as part of the AKS. Please, execute the script up to this step, but then use the name “MC_akstest-rg_aks04_westeurope” for the group being queried. You can also omit the -g option in case you don’t have other NSG under the subscription besides the one created as part of the AKS creation.