No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

i usually do a `pulumi preview --diff` and bake any of the changes its trying to make into my code. it does a lot of things behind the scenes if stuff isn’t explicitly defined. you can also go to the resource in Azure and look at the JSON view for the API version you’re using.

That shows the same diff as `pulumi up`. I have everything defined explicitly. I think what I might need here is to utilize `ignoreChanges` in the VirtualNetwork resource. I have never used `ignoreChanges' before and am having trouble declaring it.

`ignoreChanges: ["subnets", "virtualNetworkPeerings"]` did the trick.

Its another learning lesson for me, I guess. TF would have had that behavior by default but with Pulumi, we have to tell it what to do and and know what it wants us to tell it. :neutral_face:

I ran across the same issue today. Ended up creating the subnet as a sub-property of the VNet instead of a separate subnet resource.

I do not prefer to do it that way, especially for peerings that have another side. The `ignoreChanges` worked perfectly. I was just surprised that it could not figure that out by default. I realize now that there is indeed power in being able to declare specifically what you want it to do.

<@U04MC9F86UX> There is an open issue for this one <https://github.com/pulumi/pulumi-azure-native/issues/611> I had the same issue. Workaround is here: <https://github.com/pulumi/pulumi-azure-native/issues/611#issuecomment-721490800>

On my side i switched to classic for vnet and for subnet i used azure-native