https://pulumi.com logo
Title
a

able-oyster-47333

05/15/2022, 5:14 PM
I found in the azure virtual network deployment using automation-api that when I run the stack repeatedly, there is a phenomenon that the resources are rebuilt. In fact, I have not changed the network configuration. My output is as follows: Refreshing (network): ~ pulumi😛ulumi:Stack pulumi-prod-network refreshing pulumi😛ulumi:Stack pulumi-prod-network running ~ azure-native:resources:ResourceGroup cnn3-pulumi-network-rg refreshing ~ azure-native:network:RouteTable cnn3-pulumi-prod-app-rb01 refreshing ~ azure-native:network:VirtualNetwork cnn3-pulumi-prod-vnet01 refreshing ~ azure-native:network:Subnet app-subnet refreshing ~ azure-native:network:RouteTable cnn3-pulumi-prod-db-rb01 refreshing ~ azure-native:network:Subnet db-subnet refreshing ~ azure-native:network:NetworkSecurityGroup cnn3-pulumi-prod-app-nsg01 refreshing ~ azure-native:network:NetworkSecurityGroup cnn3-pulumi-prod-db-nsg01 refreshing azure-native:resources:ResourceGroup cnn3-pulumi-network-rg ~ azure-native:network:RouteTable cnn3-pulumi-prod-app-rb01 updated [diff: +subnets~etag] azure-native:network:Subnet app-subnet ~ azure-native:network:VirtualNetwork cnn3-pulumi-prod-vnet01 updated [diff: ~etag,subnets] ~ azure-native:network:NetworkSecurityGroup cnn3-pulumi-prod-db-nsg01 updated [diff: +subnets~defaultSecurityRules,etag] ~ azure-native:network:NetworkSecurityGroup cnn3-pulumi-prod-app-nsg01 updated [diff: +subnets~defaultSecurityRules,etag] ~ azure-native:network:RouteTable cnn3-pulumi-prod-db-rb01 updated [diff: +subnets~etag] azure-native:network:Subnet db-subnet pulumi😛ulumi:Stack pulumi-prod-network Resources: ~ 5 updated 4 unchanged Duration: 5s Refreshing (resources): ~ pulumi😛ulumi:Stack pulumi-prod-resources refreshing pulumi😛ulumi:Stack pulumi-prod-resources running pulumi😛ulumi:Stack pulumi-prod-resources Resources: 1 unchanged Duration: 1s E0516 01:20:10.189403400 5621 socket_utils_common_posix.cc:223] check for SO_REUSEPORT: {"created":"@1652635210.189353600","description":"Protocol not available","errno":92,"file":"src/core/lib/iomgr/socket_utils_common_posix.cc","file_line":202,"os_error":"Protocol not available","syscall":"getsockopt(SO_REUSEPORT)"} E0516 01:20:10.193124300 5621 fork_posix.cc:76] Other threads are currently calling into gRPC, skipping fork() handlers Updating (network): pulumi😛ulumi:Stack pulumi-prod-network running azure-native:resources:ResourceGroup cnn3-pulumi-network-rg ~ azure-native:network:VirtualNetwork cnn3-pulumi-prod-vnet01 updating [diff: -subnets] ~ azure-native:network:VirtualNetwork cnn3-pulumi-prod-vnet01 updated [diff: -subnets] azure-native:network:NetworkSecurityGroup cnn3-pulumi-prod-app-nsg01 azure-native:network:RouteTable cnn3-pulumi-prod-app-rb01 azure-native:network:NetworkSecurityGroup cnn3-pulumi-prod-db-nsg01 azure-native:network:RouteTable cnn3-pulumi-prod-db-rb01 azure-native:network:Subnet app-subnet azure-native:network:Subnet db-subnet pulumi😛ulumi:Stack pulumi-prod-network Resources: ~ 1 updated 8 unchanged Duration: 10s E0516 01:20:26.896494800 5621 fork_posix.cc:76] Other threads are currently calling into gRPC, skipping fork() handlers E0516 01:20:28.804288700 5621 fork_posix.cc:76] Other threads are currently calling into gRPC, skipping fork() handlers E0516 01:20:30.265914000 5621 fork_posix.cc:76] Other threads are currently calling into gRPC, skipping fork() handlers network update summary: { "same": 8, "update": 1 }
👀 1
c

clean-truck-93285

05/16/2022, 10:48 PM
Are you subnets nested in the virtual network or separate?
a

able-oyster-47333

05/18/2022, 7:52 AM
subnet is separate and it references the name of the vnet.
@clean-truck-93285 thank you for your reply. By looking at it step by step, when I call the method stack.refresh(on_output=print) again after the stack.up method, the returned content always contains the diff, in fact I did not change anything.
c

clean-truck-93285

05/18/2022, 11:42 AM
Azure resource manager (ARM) has a well known bug that has been around since the invention of ARM. Creating subnets separate from the vnet will cause the behavior your are seeing. This happens with ARM templates and bicep too because we all call the same API. Just nest the subnets inside the vnet.
a

able-oyster-47333

05/19/2022, 5:39 AM
@clean-truck-93285 Thanks for the reply, will there be a fix plan for this bug? Because for automation, we will rely on templates to flexibly change the subnet by passing parameters. If the nested definition in vnet lacks the corresponding flexibility, or do you have any suggestions here to declare subnet in vnet and pass the same Template loop to create subnet in same vnet.
c

clean-truck-93285

05/19/2022, 10:40 AM
I doubt Microsoft cares at this point. Here the GitHub issue I see the most when searching forums. https://github.com/Azure/azure-quickstart-templates/issues/2786 Also note I don't work for Pulumi or Microsoft. I just a cloud engineer that encountered this problem before. Thinking you could make an array outside of the vnet, save to a variable, and put that inside the vnet. Never tried but might work.